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.
signature.asc
Description: This is a digitally signed message part
