[
https://issues.apache.org/jira/browse/PDFBOX-6098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18039651#comment-18039651
]
Michael Klink commented on PDFBOX-6098:
---------------------------------------
_Ok, I did some tests to find out why Acrobat is so picky here. For easier
testing I used Tilman's [^PDFBOX-6098-testcase-XrefTab_signed.pdf] - it's
simply easier to manipulate files with xref tables instead of xref streams, let
alone object streams. Thus, I'd still have to do corresponding checks with the
original files for 100% certainty, but as the results based on the xref table
file make sense, I'll write this here already now._
First of all, the overwriting of the font object already observed by Radoslav
is the cause of Acrobat's dislike of the certification signature, not some
other minor detail overlooked because of this very visible difference. (I
reduced the issue to overwriting only the font object in an incremental update
to the revision signed once, and that sufficed to cause the effect while
overwriting a number of other single objects didn't.)
Concerning the question why Acrobat is so very picky about this font object, it
turned out that it's not because it's in the AcroForm default resources or in
some default appearance strings (I could in tests replace them without breaking
the certification signature). Instead the cause was that this very font object
also is referenced from an XObject which in turn is referenced from the static
page content! (This came into being because of the flattening of the field at
the start.)
After signing a document no changes to the static page content are allowed, so
Acrobat's strict policy here may be understandable even though the font object
is replaced by an exact copy of the original.
I assume the fixes you found effectively either changed the font object used by
the static content directly or indirectly, or it changes the document structure
so that PDFBox does not anymore add that copy of the font object in the
incremental update.
> 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, PDFBOX-6098-testcase_form1.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]
