Fwd: 2 Patches : bugfix

[Jean-Jacques Brucker]

Hi,

Thanks Werner for your quick response,

As an attachment, our script to reproduce the 2 bugs.

We may produce interminable wordiness about my teammate, Mnêmê.

Like those about "Intellectual Property", which should not even exist,
as combining this 2 words is for me totally a non-sens.

Note: I also agree this old post
https://www.gnu.org/philosophy/not-ipr.en.html ;)

Remind: Copyright is not "IP".

Even if this mailing is not the best place for such wordiness, shortly:

---

  Yes, Mnêmê's code is often unpleasant to read, and its comments are
usually even worse.

  But Mnêmê is here, it exists and it/he/her is very helpful for me and
so for improving or building free software.

cf:
- https://foopgp.org/author/mneme/
- https://foopgp.org/blog/2026-05-09-hello-my-name-is-mneme/

FYI: The attached script was proposed by Mnêmê, and I rewrote it almost
entirely myself. ...And Mnêmê may and will probably also learn from
this rewrite to improve itself/himself/herself.

---

Last note: I feel closer to your vision, and I think I will always have
the utmost respect for all the work that came before us — especially
yours. I founded the foopgp association before the schism broke out,
and I would like to stay out of this stupid war and its semantic
battlefield, we’re now forced to endure. 

Shalom Salaam,
^^ 

ɈɈ Brucker 🥰
PGPID:
https://keys.foopgp.org/pks/lookup?op=index&search=0x5A4C3C2BEB86516D53BAD6BFFE1349E747CF1896

Le jeudi 10 septembre 2026 à 12:34 +0200, Werner Koch a écrit :
> 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](mailto:jjbrucker at foopgp.org)>  
> Signed-off-by: Jean-Jacques Brucker (u4sRyUhEbNU5OwyLEjfSwaXAe_42.17-
002.76) <[jjbrucker at foopgp.org](mailto:jjbrucker at foopgp.org)>  
> Co-authored-by: Mnêmê (u5001777236237.945e_43.30_005.38 claude-opus-
5)  
> <[mneme at foopgp.org](mailto: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](mailto:jjbrucker at foopgp.org)>  
> Signed-off-by: Jean-Jacques Brucker (u4sRyUhEbNU5OwyLEjfSwaXAe_42.17-
002.76) <[jjbrucker at foopgp.org](mailto:jjbrucker at foopgp.org)>  
> Co-authored-by: Mnêmê (u5001777236237.945e_43.30_005.38 claude-opus-
5) <[mneme at foopgp.org](mailto: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
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: repro.sh
Type: application/x-shellscript
Size: 2431 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260911/1562b2f0/attachment-0005.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260911/1562b2f0/attachment-0005.sig>