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

[Andre Heinecke]

Hi,

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
> key.
> 
> 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 with the change you can remove the second part of your commit message 
now.

> +/* 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
> +#endif

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.

Regards,
Andre

-- 
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...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20161102/07e57c37/attachment.sig>