On Sun 2025-05-18 20:02:28 +0200, Sune Stolborg Vuorela wrote:
> This work in poppler has been done in full cooperation with GnuPG upstream,
> it
> is in the GnuPG backend of poppler and these signatures is created in
> g10code's namespace in the pdf files. (g10c.pgp.signature.detached)
What i'm hearing from this is that poppler wants interoperability with
other GnuPG installations, but not with other OpenPGP installations.
Is that correct? That doesn't seem like a great strategy for Poppler,
or for the PDF ecosystem. Why not produce standard padding packets?
Alternately, you could forge a phony signature packet of arbitrary
length, and use that as padding. it won't verify, but the presence of a
single verified signature should be sufficient.
> The packets used here has, as written, been available since 1998 and given
> all
> of that, I don't expect GnuPG upstream to remove the support for it.
afaict, GnuPG upstream also implicitly supports the practice of ignoring
standard padding packets during detached signature verification:
```
0 dkg@bob:~$ mkdir -m 0700 g
0 dkg@bob:~$ gpg --batch --homedir g --pinentry-mode=loopback --passphrase=''
--quick-generate-key tester
gpg: /tmp/cdtemp.3INGsv/g/trustdb.gpg: trustdb created
gpg: directory '/tmp/cdtemp.3INGsv/g/openpgp-revocs.d' created
gpg: revocation certificate stored as
'/tmp/cdtemp.3INGsv/g/openpgp-revocs.d/54DA9057C0E2F254FAE89D13266C90CBEFDE69A7.rev'
0 dkg@bob:~$ echo test > test.txt
0 dkg@bob:~$ gpg --batch --homedir g --detach-sign < test.txt --output
test.txt.sig
0 dkg@bob:~$ gpg --list-packets < test.txt.sig
# off=0 ctb=88 tag=2 hlen=2 plen=117
:signature packet: algo 22, keyid 266C90CBEFDE69A7
version 4, created 1747769160, md5len 0, sigclass 0x00
digest algo 10, begin of digest f7 4a
hashed subpkt 33 len 21 (issuer fpr v4
54DA9057C0E2F254FAE89D13266C90CBEFDE69A7)
hashed subpkt 2 len 4 (sig created 2025-05-20)
subpkt 16 len 8 (issuer key ID 266C90CBEFDE69A7)
data: [256 bits]
data: [256 bits]
0 dkg@bob:~$ cp test.txt.sig test.txt.sig.padded
0 dkg@bob:~$ printf '\325\001\000' >> test.txt.sig.padded
0 dkg@bob:~$ gpg --list-packets < test.txt.sig.padded
# off=0 ctb=88 tag=2 hlen=2 plen=117
:signature packet: algo 22, keyid 266C90CBEFDE69A7
version 4, created 1747769160, md5len 0, sigclass 0x00
digest algo 10, begin of digest f7 4a
hashed subpkt 33 len 21 (issuer fpr v4
54DA9057C0E2F254FAE89D13266C90CBEFDE69A7)
hashed subpkt 2 len 4 (sig created 2025-05-20)
subpkt 16 len 8 (issuer key ID 266C90CBEFDE69A7)
data: [256 bits]
data: [256 bits]
# off=119 ctb=d5 tag=21 hlen=2 plen=1 new-ctb
:unknown packet: type 21, length 1
dump: 00
0 dkg@bob:~$ gpg --batch --homedir g --status-file status.no-padding --verify
test.txt.sig test.txt
gpg: Signature made Tue 20 May 2025 03:26:00 PM EDT
gpg: using EDDSA key 54DA9057C0E2F254FAE89D13266C90CBEFDE69A7
gpg: checking the trustdb
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2028-05-19
gpg: Good signature from "tester" [ultimate]
0 dkg@bob:~$ gpg --batch --homedir g --status-file status.padding --verify
test.txt.sig.padded test.txt
gpg: Signature made Tue 20 May 2025 03:26:00 PM EDT
gpg: using EDDSA key 54DA9057C0E2F254FAE89D13266C90CBEFDE69A7
gpg: Good signature from "tester" [ultimate]
0 dkg@bob:~$ diff -u status.no-padding status.padding
0 dkg@bob:~$
```
As you can see from the end of this transcript, the status file
descriptor (which is what is parsed by gpgme) produces the exact same
output, whether a padding packet is present or not.
do you expect a future version of GnuPG will deliberately reject a
padding packet? If so, why?
If not, Poppler has two choices: ⓐ produce a standards-compliant comment
packet, meaning that the OpenPGP signature will interop with any
standards-compliant OpenPGP implementation; or ⓑ produce a
non-standards-compliant padding packet.
It looks to me like stock GnuPG will accept (meaning: ignore) either of
them and still verify. Choice ⓐ seems obviously preferable when
considering the ecosystem of available OpenPGP verifiers, which are
more likely to consult the standard, and may well be stricter about
unknown/undocumented packets than GnuPG is.
--dkg
