Radoslav Bielik created PDFBOX-6098:
---------------------------------------
Summary: Signatures invalidated in PDFBox 3.0.3-3.0.6
Key: PDFBOX-6098
URL: https://issues.apache.org/jira/browse/PDFBOX-6098
Project: PDFBox
Issue Type: Bug
Components: Signing
Affects Versions: 3.0.6 PDFBox, 3.0.5 PDFBox, 3.0.4 PDFBox, 3.0.3 PDFBox
Reporter: Radoslav Bielik
Attachments: CreateVisibleSignature3.zip, test_pdf.zip
I've started seeing an issue with signature validity affecting documents with
multiple signatures. Applying the 2nd signature would invalidate the 1st
signature, but this requires a very specific set of steps for the issue to
appear in the documents tested. Comparing multiple PDFBox versions, the issue
affects 3.0.3 through 3.0.6, but does not affect 3.0.0 through 3.0.2 - so I'm
wondering if this is a bug/regression, or if there are some extra steps that
need to be taken during signing in the recent releases?
For the issue to be reproducible, the following steps need to be taken, with
each individual step applied to a new copy of the PDF (simulating the
real-world use case) - signatures are applied with DocMDP set to "form filling
allowed" - 2.
- use PDFBox to set and flatten a form field (partial form flattening of single
field)
- use PDFBox to sign 1st signature field
- use PDFBox to sign 2nd signature field, filling out another form field at the
same time
If the 2nd signature does not involve form filling, the issue does not appear.
Similarly, if the field setting/flattening does not take place as the first
step (before all signatures) the issue does not appear either. Signature
validity was verified using Acrobat Pro. In case of PDFBox 3.0.3 through 3.0.6
the first signature would be flagged "invalid" (stating that "The document has
been altered or corrupted since the Certification was applied").
I have tried to write a minimal isolated test case reproducing the problem
based on the CreateVisibleSignature2 class from the PDFBox examples. The
signPDF method was modified to accept a byte[] and a ByteArrayOutputStream
instead of physical files. The attached CreateVisibleSignature3 demonstrates
the steps using testSetFieldAndFlatten and testSignPdf invoked from main(). I
hope this will work - I have just converted this from a groovy script I used
for testing - if not please let me know.
I'm also attaching a testcase.pdf along with the signed output generated using
PDFBox 3.0.2 vs. 3.0.6. The PDF itself is a "blank" PDF with just a handful of
form fields for testing. When comparing the generated outputs, the PDFs after
the 1st step are binary the same. After applying the 1st signature - they are
still the same (except for signature and timestamp differences). However, when
comparing the final output after the 2nd signature is applied, the version
produced by PDFBox 3.0.6 includes an extra "Helvetica" font object.
{{8 0 obj}}
{{<<}}
{{/BaseFont /Helvetica}}
{{/Encoding 7 0 R}}
{{/Name /Helv}}
{{/Subtype /Type1}}
{{/Type /Font}}
{{>>}}
{{endobj}}
This makes me wonder if the issue is not related to PDFBox trying to do some
font embedding related to the field value populated in the 1st step, and thus
modifying the content of the form (this form field was already flattened) and
invalidating the signature?
Thank you in advance for your help with this! I apologize if I'm not reporting
this correctly or selecting appropriate values. Please let me know if you need
more details or if the example attached doesn't work.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
