Problems building gpgmepy 2.0 against gnupg 2.5.20

[Ingo Klöcker]

On Donnerstag, 21. Mai 2026 18:37:19 Mitteleuropäische Sommerzeit Andreas 
Metzler wrote:
> On 2026-05-20 Meik Michalke via Gnupg-devel <gnupg-devel at gnupg.org> wrote:
> > Am Mittwoch, 20. Mai 2026, 07:14:18 CEST schrieb Funda Wang via Gnupg-
devel:
> > > 07:22:46 ValueError: Expected buffer of length 149, got 128
> > 
> > you need to increase the buffer size, see this patch we use in our debian
> > packages:
> > 
> > https://github.com/gpgdeb/gpgmepy/blob/gnupg/stable/debian/patches/0030-in
> > crease-buffer-of-python-test.patch
> Hello Meik,
> 
> why is this patch tagged with "Forwarded: not-needed"?

I had a brief look at this to figure out why "suddenly" a larger buffer is 
needed. After looking at the packets of the signed data I suspect that the 
culprit is the new manufacturer notation that's added to each signature, e.g.
        hashed subpkt 20 len 26 (notation: manu=2,2.5+1.12,2,2)

`man gpg` reads
    Note that unless the --compatibility-flags have a "no-manu" flag set, the
    GnuPG and Libgcrypt  major  and  minor  version  (e.g. "2.6+1.11") is
    included in signature packets and keys.

My conclusion is that we should apply the patch to gpgmepy because the test 
will fail with any newer version of gpg.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 265 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260521/15b319fc/attachment-0001.sig>