[
https://issues.apache.org/jira/browse/PDFBOX-6098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilman Hausherr updated PDFBOX-6098:
------------------------------------
Attachment: PDFBOX-6098-testcase-XrefTab_signed.pdf
> 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.3 PDFBox, 3.0.4 PDFBox, 3.0.5 PDFBox, 3.0.6 PDFBox
> Reporter: Radoslav Bielik
> Priority: Major
> Attachments: CreateVisibleSignature3.zip,
> PDFBOX-6098-testcase-XrefTab_signed.pdf, image-2025-11-12-13-46-17-030.png,
> 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]
