Fwd: 2 Patches : bugfix

[Werner Koch]

Hi!

Your mail is hard to parse, thus I copy your commit messages below which
are much easier to understand.

Here is the feature request: 

--8<---------------cut here---------------start------------->8---
gpg: Keep a mail address usable while any user id carrying it is

* g10/getkey.c (skip_unusable): When the matched user id is revoked or
expired, look for another usable user id carrying the same mail address
before declaring the key unusable.
--

A mail address may appear on several user ids of the same key -- when
the holder changes the display name, adds an identifier to it, or
replaces one user id with another carrying the same address.  Revoking
one of them then made the address unusable for encryption even though
another, perfectly usable user id still carried it.

The search returns the first indexed user id bearing the address.  If
that one happens to be a revoked twin, the whole key was skipped and gpg
reported "No public key" for an address it can plainly see.  Which user
id the keybox returns first is an implementation detail; whether an
address can be encrypted to should not depend on it.

This only relaxes the rejection when a usable user id carries the very
same address.  An address whose every user id is revoked or expired
stays unusable, which is what a revocation is for.

Reported-by: Jean-Jacques Brucker (u4sRyUhEbNU5OwyLEjfSwaXAe_42.17-002.76) <jjbrucker at foopgp.org>
Signed-off-by: Jean-Jacques Brucker (u4sRyUhEbNU5OwyLEjfSwaXAe_42.17-002.76) <jjbrucker at foopgp.org>
Co-authored-by: Mnêmê (u5001777236237.945e_43.30_005.38 claude-opus-5)
<mneme at foopgp.org>
--8<---------------cut here---------------end--------------->8---

I can see the problem you are trying to address.  The new semantic is
not fully clear and the patch needs at least to be slighly revised.


And here the bug report:

--8<---------------cut here---------------start------------->8---
gpg: Do not count attribute packets when checking the matched user id

* g10/getkey.c (skip_unusable): Skip attribute packets while counting
user ids.
--

The keybox indexes user id packets only: keybox-openpgp.c increments
info->nuids for PKT_USER_ID and ignores PKT_ATTRIBUTE.  gpg, on the
other hand, stores attribute packets as user ids -- parse-packet.c says
so in as many words: "we store it in the userID".

skip_unusable counted both kinds, so UID_NO -- the index the keybox
reports for the matching user id -- was shifted by the number of
attribute packets appearing before the match.  The function then tested
a different user id than the one that matched, and sometimes a photo.

On a key carrying two photo ids, encrypting to an address whose user id
sits after them was refused because a *revoked photo* was tested in its
place; conversely an address whose only user ids are revoked was
accepted because a live user id further down was tested instead.  Both
directions are wrong and neither is visible to the user: the failing one
reports "No public key".

Reported-by: Jean-Jacques Brucker (u4sRyUhEbNU5OwyLEjfSwaXAe_42.17-002.76) <jjbrucker at foopgp.org>
Signed-off-by: Jean-Jacques Brucker (u4sRyUhEbNU5OwyLEjfSwaXAe_42.17-002.76) <jjbrucker at foopgp.org>
Co-authored-by: Mnêmê (u5001777236237.945e_43.30_005.38 claude-opus-5) <mneme at foopgp.org>
--8<---------------cut here---------------end--------------->8---


That all seems to be AI generated which we won't accept because that
co-author is not able to sign the DCO which you claim by the
signed-off-by line.



Shalom-Salam,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 284 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260910/342024f7/attachment-0005.sig>