On 01/07/2026 04:45, John Scott wrote:
control: found -1 24.03.0
control: fixed -1 25.06.0
Hello,
The submitter's summary of this issue is good, but to reiterate: the version of
Poppler in Trixie will include a null byte and extra padding in the
modification date of a PDF when applying any digital signature to it. A dump of
the bytes from a signed PDF looks like this:
0x000000 / M ( D : 2 0 2 6 0 6 2 9 1 5
0x000010 3 0 5 5 - 0 4 ' 0 0 ' \0
0x000020
0x000030 ) \n
This has been fixed upstream for a while and they advise that distros
cherry-pick the fix. This doesn't depend on the user agent (Papers, Okular, or
pdfsig), the signature type (ETSI.CAdES.detached or adbe.pkcs7.detached), or
whether a new signature field or an existing one is being signed. Poppler won't
notice the error but other applications will. My opinion is this deserves to be
fixed in Debian Trixie promptly for the sake of interoperability, and because a
document being malformed is unlikely to go noticed until it's very late.
I don't maintain this package but think Poppler is pretty neat, so for the
convenience of the maintainers, I'll start preparing a merge request shortly to
cherry-pick the fix as well as add an affirmative DEP-8 (autopkgtest) check
that this suffices¹. Let me know if I should back off.
Thanks,
John
¹For me personally it is very satisfying to add a bug fix and an autopkgtest in
tandem, such that the test fails without the patch but passes with it, to prove
both necessity and sufficiency. I expect this bug is why mutool is having
trouble verifying the signature, so if my hunch is right, that's how I'll make
this work.
Please, go ahead. Also feel free to send the bug report against
release.debian.org for the trixie-pu (use reportbug to get a template).
Cheers,
Emilio
