problems with mutt's gpgme setup

[Bernhard Reiter]

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