problems with mutt's gpgme setup

[Bernhard Reiter]

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