[PATCH GnuPG] RFC: g10: Improve and unify key selection.
aheinecke at intevation.de
Wed Nov 2 14:14:25 CET 2016
Generally looks good to me. But your algroithm does not take tofu into
account. (Mine did neither). The problem is that TOFU does not affect the
validity of the UID. Which I think is a problem because it complicates things.
As you then have to check the tofu binding policy, too.
E.g. if you have a conflict both uid's will be unknown with tofu validity
unknown and the tofu policy set to ask. ( issue2817 )
Or worse for this algorithm, if a key was explicitly marked as bad in tofu it
would still be used by this algorithm as the policy is not checked. But again
this might be fixed by tofu changing the validity in that case to never.
On Wednesday 02 November 2016 12:40:58 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
> 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 with the change you can remove the second part of your commit message
> +/* First we have a struct to cache computed information about the key
> + in question. */
> +struct pubkey_cmp_cookie
> + int valid; /* Are the information valid? */
I think it should be "Is the cookie valid?"
> +static int
> +uid_is_ok (const PKT_public_key *key, const PKT_user_id *uid)
> + return key_is_ok (key) && ! uid->is_revoked
> +#if I_FIGURE_OUT_WHAT_IT_MEANS_FOR_A_UID_TO_BE_INVALID
> + && ! uid->is_invalid
I think an invalid uid may be a uid with an invalid self signature but I'm not
sure either. But in doubt so such a uid should be skipped, too.
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: 659 bytes
Desc: This is a digitally signed message part.
More information about the Gnupg-devel