[
https://issues.apache.org/jira/browse/PDFBOX-6098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18039932#comment-18039932
]
Michael Klink commented on PDFBOX-6098:
---------------------------------------
Radoslav,
Yes, just like Tilman said, your findings are compatible with my analysis:
{quote}if I remove that "if" condition and simply add a new font resource into
the DR dictionary, the issue is gone{quote}
Right, after replacing all those fonts in the default resources it doesn't
cause an issue anymore if PDFBox in the course of form fill-in adds a copy of
the font object from the default resources to the incremental update as this
font object is not referenced from the static page content.
{quote}it doesn't seem to be doing harm by adding the same alias to DR
repeatedly, and the signatures remain valid. So I'm wondering if this would be
the right solution (to apply this to all fields being modified during signing)
or if there is a better way to do it?{quote}
Usually it won't cause any harm because in most cases those names will be used
for the same kind of standard 14 fonts as you set them to. There may be PDFs,
though, that use those names for other fonts, and in that case you might change
the visual appearance of new form fill-ins.
Also this "fix" won't resolve the issue for all PDFs as there may be fonts with
other names in the default resources, too, which your code does not replace.
If you only have a limited set of base PDFs that you need to process, and if
for all those base PDFs your work-around works, just go ahead and use it. But
make a mental note to check again once new base PDFs need to be supported.
> 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-update1.zip,
> 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]
