From bernhard at intevation.de Tue Mar 1 21:27:26 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue Mar 1 21:23:32 2005 Subject: problems with mutt's gpgme setup In-Reply-To: <20050215174657.GB2721@lap200.cdc.informatik.tu-darmstadt.de> References: <20050126115002.GH4589@raktajino.does-not-exist.org> <20050127175406.GA4715@amelie.frognet.net> <20050127224021.GD4140@lap200.cdc.informatik.tu-darmstadt.de> <87y8ed51yd.fsf@wheatstone.g10code.de> <20050128131019.GC3505@lap200.cdc.informatik.tu-darmstadt.de> <20050211200127.GA20165@lap200.cdc.informatik.tu-darmstadt.de> <87vf8vea52.fsf@wheatstone.g10code.de> <20050214160810.GA11279@lap200.cdc.informatik.tu-darmstadt.de> <871xbianub.fsf@wheatstone.g10code.de> <20050215174657.GB2721@lap200.cdc.informatik.tu-darmstadt.de> Message-ID: <20050301202726.GK23103@intevation.de> On Tue, Feb 15, 2005 at 06:46:58PM +0100, Christoph Ludwig wrote: > b) When I selected the certificate for the signature I was presented with the > following choice: > > 1 x 1023/0x19442EB3 RSA es > 2 x 1024/0xC1D60643 RSA es > > I happened to know that 0x19442EB3 was my old certificate. Since I just had > imported the PKCS#12 file with my new key I erroneously assumed 0xC1D60643 > to designate my new certificate. (In fact, it designates an old, long > expired certificate that I had forgotten.) So I selected the latter > certificate and wondered about the resulting error message. Note there are two workarounds at this point: a) hit the check signature funcation (usually bound to 'c') b) Once you have figured out which key to use, set a default sign-as in .muttrc with set smime_default_key=0xXXXXXXXX > 1) I'd like to associate a string with each certificate that is printed in > addition to the certificate ID. Then I could assign each certificate a > meaningful label. I think the meaning full label is not necessary and might be even a bit missleading, if user say "good" or so and the certificate is not good or so. > 2) I want to be given a choice among *valid* certificates only when > selecting a certificate for a signature. I agree that 2) would be useful, at least the information should be displayed better in the case of a expired certificate. If you like you can add this to the ?gypten tracker as wish. https://intevation.de/roundup/aegypten Best, Bernhard -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1310 bytes Desc: not available Url : /pipermail/attachments/20050301/20d56818/smime.bin From cludwig at cdc.informatik.tu-darmstadt.de Wed Mar 2 11:25:00 2005 From: cludwig at cdc.informatik.tu-darmstadt.de (Christoph Ludwig) Date: Wed Mar 2 11:21:45 2005 Subject: problems with mutt's gpgme setup In-Reply-To: <20050301202726.GK23103@intevation.de> References: <20050127175406.GA4715@amelie.frognet.net> <20050127224021.GD4140@lap200.cdc.informatik.tu-darmstadt.de> <87y8ed51yd.fsf@wheatstone.g10code.de> <20050128131019.GC3505@lap200.cdc.informatik.tu-darmstadt.de> <20050211200127.GA20165@lap200.cdc.informatik.tu-darmstadt.de> <87vf8vea52.fsf@wheatstone.g10code.de> <20050214160810.GA11279@lap200.cdc.informatik.tu-darmstadt.de> <871xbianub.fsf@wheatstone.g10code.de> <20050215174657.GB2721@lap200.cdc.informatik.tu-darmstadt.de> <20050301202726.GK23103@intevation.de> Message-ID: <20050302102500.GD2726@lap200.cdc.informatik.tu-darmstadt.de> On Tue, Mar 01, 2005 at 09:27:26PM +0100, Bernhard Reiter wrote: > On Tue, Feb 15, 2005 at 06:46:58PM +0100, Christoph Ludwig wrote: > > > b) When I selected the certificate for the signature I was presented with the > > following choice: > > > > 1 x 1023/0x19442EB3 RSA es > > 2 x 1024/0xC1D60643 RSA es > > > > I happened to know that 0x19442EB3 was my old certificate. Since I just had > > imported the PKCS#12 file with my new key I erroneously assumed 0xC1D60643 > > to designate my new certificate. (In fact, it designates an old, long > > expired certificate that I had forgotten.) So I selected the latter > > certificate and wondered about the resulting error message. > > Note there are two workarounds at this point: > a) hit the check signature funcation (usually bound to 'c') Thanks. Let me nit-pick, though: If I am in the key selection menu and press '?' for help, then I am told that 'c' checks *PGP* keys. Of course, verify-key also works for x509 certificates, but that is not implied by the help message. Another point: The function "verify-key" is unfortunately named IMHO, because it does not do what its name conveys. (a) If used in a S/MIME setting, it operates on certificates, not keys. (I am not sure whether the distinction between a public key and the certificate that binds the key to an identity matters for Joe Average or if it only causes confusion. OTOH, as soon as one has two different certificates for one key the terminology needs to be clear.) (b) I tested the function with certificates in my key store that cannot be validated. (The first has no valid from / to fields, the second has no trusted root cert in the key store.) In both cases the relevant data from all certs in the cert chain is displayed, but I get no message that there is a problem with the certificates. > b) Once you have figured out which key to use, set a default > sign-as in .muttrc with set smime_default_key=0xXXXXXXXX Sure, that's what I did. > > 1) I'd like to associate a string with each certificate that is printed in > > addition to the certificate ID. Then I could assign each certificate a > > meaningful label. > > I think the meaning full label is not necessary and might be even a > bit missleading, if user say "good" or so and the certificate is not good > or so. I am not sure I understand your point. I want to associate the label when I include the certificate in *my* key store. Of course, nobody stops me from tagging a certificate that expires tomorrow with the string "a super-duper cert that will be always valid". I can always shoot me in the foot myself. But then I am the only one who the tag is presented to in the key selection menu. I therefore do not see how such a label could be abused to deceive someone else. > > 2) I want to be given a choice among *valid* certificates only when > > selecting a certificate for a signature. > > I agree that 2) would be useful, at least the information should be displayed > better in the case of a expired certificate. > If you like you can add this to the ?gypten tracker as wish. > https://intevation.de/roundup/aegypten Will do, thanks. I had a discussion with colleagues whether we should ask students taking our computer lab course to taggle issues we have with the S/MIME support in GnuPG / mutt. (Don't hold your breath - the number of students who can produce good quality C/C++ code is unfortunately quite small.) If we actually do this, where should we coordinate what we ask our students to work on? There might be patches you do not agree with and that will not go into GnuPG, but if we ask our students to resolve problems also mentioned on the ?gypten tracker then I want to make sure it's not something you are also working on. (The tracker shows many items where the last reported activity was several months ago. Does that mean that nobody is working on them or where they eventually resolved but for some reason never closed in the tracking system?) And where do you discuss proposed patches? Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html From duncan at lithgow-schmidt.dk Sun Mar 13 08:34:00 2005 From: duncan at lithgow-schmidt.dk (Duncan Lithgow) Date: Sun Mar 13 11:46:10 2005 Subject: can't add new keys Message-ID: <1110699241.5912.9.camel@3e6b3687.rev.stofanet.dk> Hi all, I've been trying to use gpa for a bit now but not having much luck. I'm pretty new to gpg. I've got my keyring in and my own keys work fine. But I just can't get it to retrieve any new keys at all. I've tried on the servers listed below: I found this key for Gregory P. Amos 0xA1058D40 who seems to be a developer of GPA, here's the responses: ldap://pgp.surfnet.nl:11370 -> gpgkeys: internal bind error: Can't contact LDAP server ldap://keyserver.pgp.com -> gpgkeys: LDAP search error: No such object hkp://pgp.mit.edu -> There is no plugin available for the keyserver protocol you specified hkp://keyserver.kjsl.com -> There is no plugin available for the keyserver protocol you specified I'd love some help getting this working Duncan -- Linux user #372812 GPG Key 0x21A8C63A From bernhard at intevation.de Tue Mar 29 15:53:59 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue Mar 29 15:49:58 2005 Subject: can't add new keys In-Reply-To: <1110699241.5912.9.camel@3e6b3687.rev.stofanet.dk> References: <1110699241.5912.9.camel@3e6b3687.rev.stofanet.dk> Message-ID: <20050329135359.GD29777@intevation.de> On Sun, Mar 13, 2005 at 08:34:00AM +0100, Duncan Lithgow wrote: > I've been trying to use gpa for a bit now but not having much luck. Which version of gpa and gnupg are you trying BTW? > I'm > pretty new to gpg. I've got my keyring in and my own keys work fine. But > I just can't get it to retrieve any new keys at all. I've tried on the > servers listed below: > > I found this key for Gregory P. Amos 0xA1058D40 who seems to be a > developer of GPA, here's the responses: > > ldap://pgp.surfnet.nl:11370 > -> gpgkeys: internal bind error: Can't contact LDAP server > > ldap://keyserver.pgp.com > -> gpgkeys: LDAP search error: No such object > > hkp://pgp.mit.edu > -> There is no plugin available for the keyserver protocol you specified > > hkp://keyserver.kjsl.com > -> There is no plugin available for the keyserver protocol you specified > > I'd love some help getting this working -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20050329/db8f42f0/attachment.pgp From bernhard at intevation.de Tue Mar 29 16:03:50 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue Mar 29 15:59:50 2005 Subject: problems with mutt's gpgme setup In-Reply-To: <20050302102500.GD2726@lap200.cdc.informatik.tu-darmstadt.de> References: <20050127224021.GD4140@lap200.cdc.informatik.tu-darmstadt.de> <87y8ed51yd.fsf@wheatstone.g10code.de> <20050128131019.GC3505@lap200.cdc.informatik.tu-darmstadt.de> <20050211200127.GA20165@lap200.cdc.informatik.tu-darmstadt.de> <87vf8vea52.fsf@wheatstone.g10code.de> <20050214160810.GA11279@lap200.cdc.informatik.tu-darmstadt.de> <871xbianub.fsf@wheatstone.g10code.de> <20050215174657.GB2721@lap200.cdc.informatik.tu-darmstadt.de> <20050301202726.GK23103@intevation.de> <20050302102500.GD2726@lap200.cdc.informatik.tu-darmstadt.de> Message-ID: <20050329140350.GE29777@intevation.de> Hi Christoph, sorry for answering so late, this email somehow slipped. (For future reference: Ping me by email if you think that I might have missed an email on this public list.) On Wed, Mar 02, 2005 at 11:25:00AM +0100, Christoph Ludwig wrote: > On Tue, Mar 01, 2005 at 09:27:26PM +0100, Bernhard Reiter wrote: > > On Tue, Feb 15, 2005 at 06:46:58PM +0100, Christoph Ludwig wrote: > > Note there are two workarounds at this point: > > a) hit the check signature funcation (usually bound to 'c') > > Thanks. Let me nit-pick, though: If I am in the key selection menu and press > '?' for help, then I am told that 'c' checks *PGP* keys. Of course, verify-key > also works for x509 certificates, but that is not implied by the help > message. > > Another point: The function "verify-key" is unfortunately named IMHO, because > it does not do what its name conveys. (a) If used in a S/MIME setting, it > operates on certificates, not keys. (I am not sure whether the distinction > between a public key and the certificate that binds the key to an identity > matters for Joe Average or if it only causes confusion. OTOH, as soon as one > has two different certificates for one key the terminology needs to be clear.) > (b) I tested the function with certificates in my key store that cannot be > validated. (The first has no valid from / to fields, the second has no > trusted root cert in the key store.) In both cases the relevant data from all > certs in the cert chain is displayed, but I get no message that there is a > problem with the certificates. All three points are valid criticism. When looking at the other bugs, they are not first priority, though. And I hope we would have enough capacity to deal with the others first. ;) So help is appreciated. You can create issues for our tracker to make sure that the points are not lost, too. > > > 1) I'd like to associate a string with each certificate that is printed in > > > addition to the certificate ID. Then I could assign each certificate a > > > meaningful label. > > > > I think the meaning full label is not necessary and might be even a > > bit missleading, if user say "good" or so and the certificate is not good > > or so. > > I am not sure I understand your point. I want to associate the label when I > include the certificate in *my* key store. Of course, nobody stops me from > tagging a certificate that expires tomorrow with the string "a super-duper > cert that will be always valid". I can always shoot me in the foot > myself. But then I am the only one who the tag is presented to in > the key selection menu. I therefore do not see how such a label > could be abused to deceive someone else. No, it might be used to confuse yourself. My point is that the standard interface should be so good that you do not need the labels, thus avoiding that source of confusion for good. > > > > 2) I want to be given a choice among *valid* certificates only when > > > selecting a certificate for a signature. > > > > I agree that 2) would be useful, at least the information should > > be displayed better in the case of a expired certificate. If > > you like you can add this to the ?gypten tracker as wish. > > https://intevation.de/roundup/aegypten > > Will do, thanks. I haven't seen it yet. (Did I miss it?) > I had a discussion with colleagues whether we should ask students taking our > computer lab course to taggle issues we have with the S/MIME support in > GnuPG / mutt. (Don't hold your breath - the number of students who can produce > good quality C/C++ code is unfortunately quite small.) Yes, and this being in the security area makes this even a larger problem. > If we actually do this, > where should we coordinate what we ask our students to work on? Basically on this list and monitoring the relevant mutt and gnupg lists. > There might be > patches you do not agree with and that will not go into GnuPG, but if we ask > our students to resolve problems also mentioned on the ?gypten tracker then I > want to make sure it's not something you are also working on. (The tracker > shows many items where the last reported activity was several months ago. Does > that mean that nobody is working on them or where they eventually resolved but > for some reason never closed in the tracking system?) And where do you discuss > proposed patches? We discuss proposed patches here on this list or via other ways as some developer meet in person from time to time. Sometimes is also makes sense to put a patch in the tracker. The problem is the sheer number of smaller problems that we cannot tackle alone. If a bug has not been acted upon, you should always ping in the issue before working on it. Those bugs in the tracker should be real. Of course we appreciate any help, but you should not that some of the bugs might turn out really, really hard to fix. Especially the more annoying ones. Otherwise the people of g10code would have fixed it long ago. You just need to be prepared that this is not an easy exercise. ;-) Best, Bernhard -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20050329/515f9b5b/attachment.pgp From cludwig at cdc.informatik.tu-darmstadt.de Tue Mar 29 16:52:21 2005 From: cludwig at cdc.informatik.tu-darmstadt.de (Christoph Ludwig) Date: Tue Mar 29 17:49:20 2005 Subject: problems with mutt's gpgme setup In-Reply-To: <20050329140350.GE29777@intevation.de> References: <87y8ed51yd.fsf@wheatstone.g10code.de> <20050128131019.GC3505@lap200.cdc.informatik.tu-darmstadt.de> <20050211200127.GA20165@lap200.cdc.informatik.tu-darmstadt.de> <87vf8vea52.fsf@wheatstone.g10code.de> <20050214160810.GA11279@lap200.cdc.informatik.tu-darmstadt.de> <871xbianub.fsf@wheatstone.g10code.de> <20050215174657.GB2721@lap200.cdc.informatik.tu-darmstadt.de> <20050301202726.GK23103@intevation.de> <20050302102500.GD2726@lap200.cdc.informatik.tu-darmstadt.de> <20050329140350.GE29777@intevation.de> Message-ID: <20050329145220.GA6764@lap200.cdc.informatik.tu-darmstadt.de> Hi Bernhard, On Tue, Mar 29, 2005 at 04:03:50PM +0200, Bernhard Reiter wrote: > sorry for answering so late, this email somehow slipped. no problem. > (For future reference: Ping me by email if you think that I might > have missed an email on this public list.) Noted, thanks. > On Wed, Mar 02, 2005 at 11:25:00AM +0100, Christoph Ludwig wrote: > > On Tue, Mar 01, 2005 at 09:27:26PM +0100, Bernhard Reiter wrote: > > > On Tue, Feb 15, 2005 at 06:46:58PM +0100, Christoph Ludwig wrote: > > > > Note there are two workarounds at this point: > > > a) hit the check signature funcation (usually bound to 'c') > > > > Thanks. Let me nit-pick, though: If I am in the key selection menu and press > > '?' for help, then I am told that 'c' checks *PGP* keys. Of course, verify-key > > also works for x509 certificates, but that is not implied by the help > > message. > > > > Another point: The function "verify-key" is unfortunately named IMHO, because > > it does not do what its name conveys. (a) If used in a S/MIME setting, it > > operates on certificates, not keys. (I am not sure whether the distinction > > between a public key and the certificate that binds the key to an identity > > matters for Joe Average or if it only causes confusion. OTOH, as soon as one > > has two different certificates for one key the terminology needs to be clear.) > > (b) I tested the function with certificates in my key store that cannot be > > validated. (The first has no valid from / to fields, the second has no > > trusted root cert in the key store.) In both cases the relevant data from all > > certs in the cert chain is displayed, but I get no message that there is a > > problem with the certificates. > > All three points are valid criticism. > When looking at the other bugs, they are not first priority, though. > And I hope we would have enough capacity to deal with the others first. ;) > > So help is appreciated. You can create issues for our tracker to > make sure that the points are not lost, too. At least the help message in mutt is not that hard to fix, so I will ask our students to do that first. (If they are not able to fix this problem, then they won't pass the lab, I guess. :-) The name of of the function "verify-key" is unfortunate, but it is not worth changing the function name throughout the code, I guess - as long as the documentation states clearly what the function does. The most serious of above problems is (b), I think; and it is probably the most complicated to fix. I will look into it and decide whether it is something I can ask our students to work on or whether I better file a problem report in your issue tracker. > > > > 1) I'd like to associate a string with each certificate that is printed in > > > > addition to the certificate ID. Then I could assign each certificate a > > > > meaningful label. > > > > > > I think the meaning full label is not necessary and might be even a > > > bit missleading, if user say "good" or so and the certificate is not good > > > or so. > > > > I am not sure I understand your point. I want to associate the label when I > > include the certificate in *my* key store. Of course, nobody stops me from > > tagging a certificate that expires tomorrow with the string "a super-duper > > cert that will be always valid". I can always shoot me in the foot > > myself. But then I am the only one who the tag is presented to in > > the key selection menu. I therefore do not see how such a label > > could be abused to deceive someone else. > > No, it might be used to confuse yourself. > My point is that the standard interface should be so good that you > do not need the labels, thus avoiding that source of confusion for good. I doubt whether it is possible to show in one 80 columns line enough information that (a) always uniquely identifies each certificate and (b) allows a human to *recognize* each certificate. (a) is guaranteed by the fingerprint but you cannot expect the users to recall the fingerprints of their certs. The information required for (b) may vary widely: You may have certs for the same id, but issued by different CAs. You may have certs that differ by their validity period only. You may have certs for one ID with different usage restrictions etc. Since you don't know in advance by which properties the user is going to distinguish the certs, you need to show essentially all fields of the cert. That is too much for one line. And even though I am everything but a usability expert I expect that you should not dump all fields in a cert selection dialog or the user won't see the wood for the trees. That is why I think it is better to leave it to the user to assign some additional tag that helps him or her to distinguish the available certs. > > > > 2) I want to be given a choice among *valid* certificates only when > > > > selecting a certificate for a signature. > > > > > > I agree that 2) would be useful, at least the information should > > > be displayed better in the case of a expired certificate. If > > > you like you can add this to the ?gypten tracker as wish. > > > https://intevation.de/roundup/aegypten > > > > Will do, thanks. > > I haven't seen it yet. > (Did I miss it?) It seems so. It is issue #305. > > I had a discussion with colleagues whether we should ask students taking our > > computer lab course to taggle issues we have with the S/MIME support in > > GnuPG / mutt. (Don't hold your breath - the number of students who can produce > > good quality C/C++ code is unfortunately quite small.) > > Yes, and this being in the security area makes this even a larger problem. > > > If we actually do this, > > where should we coordinate what we ask our students to work on? > > Basically on this list and monitoring the relevant mutt and gnupg lists. > > > There might be > > patches you do not agree with and that will not go into GnuPG, but if we ask > > our students to resolve problems also mentioned on the ?gypten tracker then I > > want to make sure it's not something you are also working on. (The tracker > > shows many items where the last reported activity was several months ago. Does > > that mean that nobody is working on them or where they eventually resolved but > > for some reason never closed in the tracking system?) And where do you discuss > > proposed patches? > > We discuss proposed patches here on this list or via other ways > as some developer meet in person from time to time. > Sometimes is also makes sense to put a patch in the tracker. > > The problem is the sheer number of smaller problems that we cannot > tackle alone. If a bug has not been acted upon, you should always ping > in the issue before working on it. Those bugs in the tracker should be real. > > Of course we appreciate any help, but you should not that some of > the bugs might turn out really, really hard to fix. > Especially the more annoying ones. Otherwise the people of g10code > would have fixed it long ago. You just need to be prepared that this > is not an easy exercise. ;-) OK, we will keep it in mind. Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20050329/e1d4036d/attachment-0001.pgp From bernhard at intevation.de Wed Mar 30 11:23:57 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed Mar 30 11:20:03 2005 Subject: problems with mutt's gpgme setup In-Reply-To: <20050329145220.GA6764@lap200.cdc.informatik.tu-darmstadt.de> References: <20050128131019.GC3505@lap200.cdc.informatik.tu-darmstadt.de> <20050211200127.GA20165@lap200.cdc.informatik.tu-darmstadt.de> <87vf8vea52.fsf@wheatstone.g10code.de> <20050214160810.GA11279@lap200.cdc.informatik.tu-darmstadt.de> <871xbianub.fsf@wheatstone.g10code.de> <20050215174657.GB2721@lap200.cdc.informatik.tu-darmstadt.de> <20050301202726.GK23103@intevation.de> <20050302102500.GD2726@lap200.cdc.informatik.tu-darmstadt.de> <20050329140350.GE29777@intevation.de> <20050329145220.GA6764@lap200.cdc.informatik.tu-darmstadt.de> Message-ID: <20050330092357.GA18406@intevation.de> On Tue, Mar 29, 2005 at 04:52:21PM +0200, Christoph Ludwig wrote: > On Tue, Mar 29, 2005 at 04:03:50PM +0200, Bernhard Reiter wrote: > > All three points are valid criticism. > > When looking at the other bugs, they are not first priority, though. > > And I hope we would have enough capacity to deal with the others first. ;) > > > > So help is appreciated. You can create issues for our tracker to > > make sure that the points are not lost, too. > > At least the help message in mutt is not that hard to fix, so I will ask our > students to do that first. (If they are not able to fix this problem, then > they won't pass the lab, I guess. :-) ;) > The name of of the function "verify-key" is unfortunate, but it is not worth > changing the function name throughout the code, I guess - as long as the > documentation states clearly what the function does. I agree. > The most serious of above problems is (b), I think; and it is probably the > most complicated to fix. I will look into it and decide whether it is > something I can ask our students to work on or whether I better file a problem > report in your issue tracker. Thanks. > > My point is that the standard interface should be so good that you > > do not need the labels, thus avoiding that source of confusion for good. > > I doubt whether it is possible to show in one 80 columns line enough > information that (a) always uniquely identifies each certificate and (b) > allows a human to *recognize* each certificate. (a) is guaranteed by the > fingerprint but you cannot expect the users to recall the fingerprints of > their certs. The information required for (b) may vary widely: You may have > certs for the same id, but issued by different CAs. You may have certs that > differ by their validity period only. You may have certs for one ID with > different usage restrictions etc. > > Since you don't know in advance by which properties the user is going to > distinguish the certs, you need to show essentially all fields of the cert. > That is too much for one line. And even though I am everything but a usability > expert I expect that you should not dump all fields in a cert selection dialog > or the user won't see the wood for the trees. > > That is why I think it is better to leave it to the user to assign some > additional tag that helps him or her to distinguish the available certs. I agree that there need to be further criteria to limit what is displayed. My idea is that therefore a label is not necessary, but that the user can use a different application (e.g. like gpa or kleopatra) to make the necessary settings so that mutt will only propose the best uids by default. The goal should be that mutt does not need to select keys at all. For KMail and KAddressbook during ?gypten2 we implemented settings that saved the crypto preference of each address. So the goal should be: In normal situation when sending email: No key selection should be necessary. Other applications can completely deal with all options. > > > > > 2) I want to be given a choice among *valid* certificates only when > > > > > selecting a certificate for a signature. > > > > > > > > I agree that 2) would be useful, at least the information should > > > > be displayed better in the case of a expired certificate. If > > > > you like you can add this to the ?gypten tracker as wish. > > > > https://intevation.de/roundup/aegypten > > > > > > Will do, thanks. > > > > I haven't seen it yet. > > (Did I miss it?) > > It seems so. It is issue #305. Ah, thanks. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20050330/d47b91af/attachment.pgp From duncan at lithgow-schmidt.dk Wed Mar 30 16:40:48 2005 From: duncan at lithgow-schmidt.dk (Duncan Lithgow) Date: Thu Mar 31 06:40:28 2005 Subject: can't add new keys In-Reply-To: <20050329135359.GD29777@intevation.de> References: <1110699241.5912.9.camel@3e6b3687.rev.stofanet.dk> <20050329135359.GD29777@intevation.de> Message-ID: <1112193648.5922.40.camel@3e6b2703.rev.stofanet.dk> On Tue, Mar 29, 2005 at 05:30:01PM +0200, Duncan Lithgow wrote: > > Which version of gpa and gnupg are you trying BTW? > > > Aha! The list is alive :-) > Sure, it is, though slow sometimes. > Can you also send your answer to the list then. ;) My problems importing keys are with these versions: gpa: 0.7.0 gnupg 1.2.6-1@i386 gnupg2 1.9.15-1@i386 From huehn-ml at arcor.de Wed Mar 30 16:14:33 2005 From: huehn-ml at arcor.de (Thomas =?iso-8859-1?q?H=FChn?=) Date: Thu Mar 31 06:41:02 2005 Subject: OpenPGP smartcard and KMail (KDE 3.4) Message-ID: <200503301614.33147.huehn-ml@arcor.de> Hi I've filed a bug with KMail (http://bugs.kde.org/show_bug.cgi?id=102478) and was told that you're the ones to ask. I try to encrypt/sign a mail (OpenPGP/MIME) with KMail. The private key resides on a OpenPGP smartcard; GnuPG version is 1.4.0 from Debian unstable. KDE version is 3.4 (from http://pkg-kde.alioth.debian.org/kde-3.4.0/). KMail never asks for the smartcard's PIN and hangs. Until I kill the gpg process (in this case "gpg --no-sk-comment --status-fd 41 --no-tty --charset utf8 --enable-progress-filter --command-fd 43 --sign --detach --armor -u 0F2B3C20E772CFE9"). Using a key that isn't on the smartcard works. Is this a misconfiguration or a bug? What can be done? Thomas H?hn From michaelnottebrock at gmx.net Wed Mar 30 17:35:27 2005 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Thu Mar 31 06:41:07 2005 Subject: Incompatible passphrase encoding in gpg/gpg-agent? Message-ID: <200503301735.34284.michaelnottebrock@gmx.net> I have recently received a bugreport about pinentry-qt not handling the "?" character correctly. After some testing it turns out that gpg, if used without gpg-agent seems to encode passphrases differently than the agents do. Testcase: Run gpg without agent active, use passwd to change a key passphrase to "test?test". Save. Then run gpg-agent (any pinentry variant will do) and try to change the passphrase again with gpg. Gpg won't accept the passphrase string delivered by gpg-agent. Unset the GPG_AGENT_INFO env var and change passphrase in gpg without agent - works. This is with gpg from GnuPG 1.4.0, gpg-agent from GnuPG 1.9.14 and pinentry 0.7.1. -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : /pipermail/attachments/20050330/feb528bd/attachment.pgp From wk at gnupg.org Thu Mar 31 09:46:04 2005 From: wk at gnupg.org (Werner Koch) Date: Thu Mar 31 09:46:30 2005 Subject: OpenPGP smartcard and KMail (KDE 3.4) In-Reply-To: <200503301614.33147.huehn-ml@arcor.de> ( =?utf-8?q?Thomas_H=C3=BChn's_message_of?= "Wed, 30 Mar 2005 16:14:33 +0200") References: <200503301614.33147.huehn-ml@arcor.de> Message-ID: <87vf785kcj.fsf@wheatstone.g10code.de> On Wed, 30 Mar 2005 16:14:33 +0200, Thomas H?hn said: > KMail never asks for the smartcard's PIN and hangs. Until I kill the gpg I assume you are not using the gpg-agent. It is either a bug in GPGME's passphrase callback code or even one in Kmail. Please run KMail this way: GPGME_DEBUG=5:/tmp/gpgme.dbg: kmail and send me gpgme.dbg by PM. Passphrases or PINs entered durng this session are visible in gpgme.dbg but as it doesn't ask you it shouldn't be a problem. Salam-Shalom, Werner