[pkg-gnupg-maint] Bug#1105820: Bug#1105820: Bug#1105820: Bug#1105820: Bug#1105820: Gnupg-in-debian considers comment packets invalid

[Sune Stolborg Vuorela]

Hi Daniel

Thank you for your reply. 

I'm not sure why all of this matters; there are others that expects gnupg in 
Debian to validate and fail things in a similar way to gnupg-from-upstream and 
gnupg-in-other distributions.

I don't think that is an unreasonable request.

And poppler is released, used by others. Not only in Debian, but also in other 
places, and it generates these documents. We should not reject them just 
because we can. 
It has also been implemented based on user requests. 

But nevertheless, let me try to at least address some of your questions. Given 
that I actually wrote and pushed the code in question to poppler, I actually 
know about a lot of 'why'.

On Friday, May 16, 2025 4:54:46 PM CEST Daniel Kahn Gillmor wrote:
> 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.

Note that it is using GpgME to talk to GnuPG, not to do RFC9580 which GnuPG 
does not support, so all references to RFC9580 is not relevant here.

Also note that this is more or less piggy-backing on top of the S/Mime (X509) 
implementation that talks to gpg for S/Mime (X509) handling.

And these private packets are fully compliant. It is in the spec after all. 
And as I wrote, these packets have been around since 1998, which is at least 
way before I heard of GnuPG, let alone co-maintained it in Debian.

> Why is padding needed in this case?

In a the signed part of a PDF file, it is described that the signature is 
stored in a specific part of a PDF file (The signature covers bytes A to B and C 
to D (and the signature needs to be stored between B and C)), so there this 
hole that contains the signature, but given the location in the file needs to 
be specified before signing the data, it must be bigger than the expected 
signature size. 

There was more or less 4 ways of doing it
1) Do a gpg packet parser in poppler to only pass the actual signature part of 
the signature area on to GnuPG
2) Wrap it in an extra level of indirection with some kind of (datasize, data) 
structure
3) Use something the underlying implementation would happily accept and 
discard of a variable size to make it fit in the middle of the pdf file. 
4) Sign some dummy data first with the key in question, check the size of the 
signature and hope that a repeat signature of different data will have the 
exact same size.

4) involves the word 'hope' and is thus a bad idea. Also for people not using 
an agent to remember passphrases or using some kind of touch-to-sign 
smartcard, it is an annoying and surprising workflow ("Why do I need to sign 
twice").

Given that there already is a battle tested package parser in GnuPG, makes 3) 
a much better choice than 1.

Using 3) would also make it easier for e.g. pdfsig or just 'cut' to dump the 
signature into something that one manually can process with GnuPG, just like 
how you can do it with S/Mime signatures and process it manually with openssl, 
gpgsm or whatever tool you want to do without any other faffing around, so that 
kind of is points against 2. 

One could maybe use multiple 'marker' packets, but they seem to be fixed length 
packets just complicating it again.

So simplicity was chosen. Towards the library-implementation that was already 
in the stack.
 
> 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?

Currently, the goal is for users to be able to sign and validate documents 
without having a properly issued (likely governmental) S/Mime certificate on 
multiple operating systems.

> 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. 

But that would require understanding the packets rather than just passing it 
on to the underlying implementation, thus complicating the code and increase 
complexity of poppler.

A packet parser alone would likely double the amount of code needed in Poppler 
for this feature.



/Sune
-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank