[PATCH GnuPG] RFC: g10: Improve and unify key selection.

[Justus Winter]

Andre Heinecke <aheinecke at intevation.de> writes:
> 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
>> key.
>
> 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.

Right, I mis-read the algorithm you posted in the bug report.

>> 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
>> constraint.
>
> 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.

Ok, I'll revise the patch.

Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 454 bytes
Desc: not available
URL: </pipermail/attachments/20161031/c7f0f266/attachment.sig>