Signing an already signed document changes /MediaBox type from NumberObject to FloatObject about pyhanko HOT 4 CLOSED

Sure, I'd certainly be happy to consider a pull request when you're done. I admittedly didn't give much thought to supporting SubFilter values that aren't listed in the (PDF) standard, though, so perhaps it makes sense to rearrange a few things to make that easier going forward. That shouldn't involve too much work, though. :)

EDIT: By the way, "%s" % str(self) is equivalent to just str(self), for what it's worth.

from pyhanko.

Thanks for the detailed bug report! Odds are that the problem has to do with comparison routines not dealing with mixed-type comparisons properly; I'll look into that. Just for good measure: can you share the signed file?

from pyhanko.

Thanks for the detailed bug report! Odds are that the problem has to do with comparison routines not dealing with mixed-type comparisons properly; I'll look into that. Just for good measure: can you share the signed file?

The strangest thing is that the digest seems to validate. I suppose that the signature encompass the original MediaBox property, so the problem might be on the type casting of parser of the old or the new coordinates, or, eventually, in the new pdf file saving.

Being more permissive on the mixed-type comparisons should work, but I wonder if it could create other issues or weaken the validation.

I am attaching sample pdf files (unsigned, one signature -- externally signed with a Brazilian valid CA --, and two signatures -- the second using pyhanko and self-signed pem certs) using PBAD-PAdES, that is the same standard I used for the tests. I will try to test with the standard ETSI-PADES, however, I do not think that this is source of the issue.

In the fork I am working on there are the changes needed to validate this kind of file changes from original project

So far just minor changes needed, actually just adding the /SubFilter PBAD-PAdES does the trick -- I have also added an option to not ask passphrase to the pemder to make my tests easier, in production I'll use a passphrase file as I should.

from pyhanko.

Thanks for sharing! From a quick inspection of your files, it seems that the issue is that pyHanko reserialises the page object with a different precision. The underlying reason for that is that it uses %g to serialise FloatObject values, which apparently cuts off its input at 10^-4 (the original width / height of the page is actually 595.32001 x 841.92004). This is (partially) a holdover from PyPDF2.

Internally, pyHanko still uses Decimal objects, so the part of the validation logic that vets updates to signed files complains that the values don't match.

Could you try changing the last line in the __repr__ implementation for FloatObject to return str(self) and recreate the signature? I think that should resolve your issue. If it does, I'll commit it with some tests.

from pyhanko.