[pkg-gnupg-maint] Bug#1105820: Bug#1105820: Bug#1105820: Bug#1105820: Gnupg-in-debian considers comment packets invalid
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Fri May 16 15:54:46 BST 2025
Hi Sune--
On Fri 2025-05-16 10:33:28 -0400, Daniel Kahn Gillmor wrote:
> Looking at your sample PDF (thanks for the link!) it appears that it is
> a comment packet of length 0x24d4 containing all zeros. What is the
> purpose of this packet? Why is it being included?
>
> Rather than increasing the attack surface of GnuPG, maybe whatever
> implementation is producing this thing shouldn't emit a
> private/experimental packet sequence.
I just found:
https://gitlab.freedesktop.org/poppler/poppler/-/commit/f0316ba62df9ce6d8e17a9349934b4a06df87e69
It looks like this was added very recently, well after RFC 9580 came
out, and injects these arbitrary private/experimental packets, strictly
for padding purposes.
Why is padding needed in this case?
In section 10.4, RFC 9580 explicitly observes that for detached
signatures (which i think is the closest characterization of the thing
you're looking to add to the PDF standard here):
>>> In addition, a Marker packet (Section 5.8) and a Padding packet
>>> (Section 5.14) can appear anywhere in the sequence.
If padding is what's needed here, i recommend using standardized padding
that any compliant OpenPGP implementation will accept. Presumably the
goal is for arbitrary OpenPGP consumers to be able to verify the
signature of the PDF, right?
Alternately, if you want to pad a signature packet, you can also inject
arbitrary non-critical subpackets into the unhashed subpacket area of
the signature itself; those subpackets should be ignored by every
OpenPGP implementation i'm aware of.
All of this padding flexibility, of course, enables the production of an
arbitrary covert sidechannel in these signature formats. But as you
say, those sidechannels have been part of OpenPGP for ages.
The GnuPG patchset offered by Demi Marie tightens up OpenPGP's packet
grammar significantly, reducing the attack surface.
I'd really prefer to not drop that security enhancement to accomodate
recently introduced changes in unrelated software that are themselves
not compliant with any standards i'm aware of.
--dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20250516/1de033bf/attachment.sig>
More information about the pkg-gnupg-maint
mailing list