Validation errors after upgrading pyhanko-certvalidator from 0.12.1 to 0.15.1 about pyhanko HOT 3 CLOSED

Hi Matthias,

It did the trick, the validation occurred as expected, The two firsts were considered valid and the latter invalid.

Regarding the pdf standard 'openness', I know what you mean. I made an wrapper to enable multithread/multiserver batch OCR scanning (https://github.com/gchehab/ocr-server) and the many diverse ways an embedded image may be encoded almost drove me nuts, I am quite sure that there are a lot of cases that I failed to address.

I just got my hands on another PDF that a colleague is working on that gives a type error during its parse while validating, I am not sure, however if the issue is not some error on the PDF file signature itself. I'll open an issue specific for this error.

Thank you for your quick support,
Guilherme

from pyhanko.

Hi, thanks for the report!

The first issue has to do with incremental update validation in pyHanko, and can be solved by whitelisting one more key. Someone else had the same issue; I'll do a bugfix release to correct that particular problem soon. In the meantime, here's how to work around the problem by defining your own diff policy:

As for the workaround, here's the declaration of the default diff
analysis policy:

pyHanko/pyhanko/sign/diff_analysis.py

Line 2146 in fd1af25

DEFAULT_DIFF_POLICY = StandardDiffPolicy(

.
You can define a custom diff policy to get around this kind of thing,
and pass it as the diff_policy parameter in various validation methods.

Start by copying the default rules, since you probably want to preserve
most of those. The FormUpdatingRule class actually takes another
parameter called ignored_acroform_keys where you can pass in keys that
are to be ignored in the "strict" part of the comparison comparison
analysis. Passing in "{'/Fields', '/DA', '/DR'}" should be OK.

Alternatively, you can cheat and add "/DA" to the list of keys in
pyhanko.sign.diff_analysis.ACROFORM_EXEMPT_STRICT_COMPARISON at runtime.
Then it will work automagically with the default diff policy

The second issue is indeed certvalidator-related. It tries to fetch some related certs from a CRL AIA record, but the server isn't setting the Content-Type header. That's is a bit annoying, because there are multiple ways to encode certs in a situation like this, and ordinarily you'd rely on the Content-Type header to select the correct parser. I suspect that this particular fetch wasn't working all along, and my move from urllib to requests in my fork of certvalidator simply broke the error handling code. I'd guess that the certs that certvalidator was trying to fetch were actually already available in the local cache anyway.

I'll look into this one more closely, and do a bugfix release if necessary. Thanks for bringing it to my attention!

from pyhanko.

Hi, can you reproduce the problem with the latest HEAD for pyHanko and pyhanko-certvalidator? Your file passes validation on my machine now (well, the last signer's certificate doesn't jive with pyHanko's default key usage policy, but you can easily change that in the configuration file).

If this fixes your issue, then I'll do a bugfix release for pyhanko-certvalidator, update the dependency in pyHanko itself, and do a bugfix release here as well. :)

PS: If you face similar diff analysis issues in the future, please report them if you can. This aspect of PDF signature validation isn't standardised anywhere (yet), so I'm always on the lookout for interesting corner cases.

from pyhanko.