[PATCH GnuPG] RFC: g10: Improve and unify key selection.
aheinecke at intevation.de
Mon Oct 31 15:51:29 CET 2016
On Monday 31 October 2016 13:12:16 Justus Winter wrote:
> When a name resembling a mail address is given to either --locate-key
> or --recipient, rank the search results and use only the most relevant
I would prefer it if this function would also return expired / revoked /
validitity never etc. Keys. So in a GUI we could handle this case by informing
the user that the key for this user is expired.
Otherwise we would have to check for that case with another keylisting to
avoid the problem that a user was able to encrypt to someone yesterday
automatically and today it no longer works and the UI just shows "No key for
this recipient" when a UI uses locate-keys.
> This also lets us query which key will be used for encryption using
> --locate-key. XXX: Is this true? B/c if we use --recipient, we only
> consider keys usable for encryption. Otoh, --locate-key has no such
I think this could be solved by ranking a key that can both encrypt higher
then a key that can't encrypt. This would avoid the state where an encrypt key
can can't be found because a user has a different primary key with only signing
(for whatever weird reason). The primary usecase of this function imo is to
look up recipient keys for encryption.
Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 630 bytes
Desc: This is a digitally signed message part.
More information about the Gnupg-devel