problems with mutt's gpgme setup

Tue Mar 29 16:52:21 CEST 2005

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