[
https://issues.apache.org/jira/browse/PDFBOX-6098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18039898#comment-18039898
]
Radoslav Bielik edited comment on PDFBOX-6098 at 11/21/25 3:11 PM:
-------------------------------------------------------------------
Sorry it took me so long to follow up. So we typically get PDFs from external
sources and I have a sample (that I unfortunately cannot share) that suffers
from this issue even if testSetFieldAndFlatten() isn't called before applying
multiple signatures. This one would also be "fixed" by downgrading to PDFBox
3.0.2.
But I also have a fixFieldFont() helper method that I had to use in the past to
fix some weird PDFs by adding font aliases to the DR dictionary - this is what
I was referring to in my reply from Nov 18. The original version of the
fixFieldFont() method would check if the DR doesn't already contain the font
alias - but if I remove that "if" condition and simply add a new font resource
into the DR dictionary, the issue is gone.
[^CreateVisibleSignature3-update1.zip]
I have updated the CreateVisibleSignature3 example by adding two overloads of
fixFieldFont and added a call to this method to line 582 of testSignPdf(). Now
- once again, I might be doing something completely wrong here (or
overcomplicating things) but 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?
The important thing to note here is that I can reproduce the issue (and the
fix) also on a PDF where I do not make the testSetFieldAndFlatten() call and do
not perform partial flattening (but I can't share that file now). I'm not sure
how that document was authored - PDF Producer is "Adobe PDF Library 20.6.66"
and PDF Version is "1.6 (Acrobat 7.x)" - but it may have had other
modifications applied to it as well.
Thank you again for all your help!
was (Author: rado):
Sorry it took me so long to follow up. So we typically get PDFs from external
sources and I have a sample (that I unfortunately cannot share) that suffers
from this issue even if testSetFieldAndFlatten() isn't called before applying
multiple signatures. This one would also be "fixed" by downgrading to PDFBox
3.0.2.
But I also have a fixFieldFont() helper method that I had to use in the past to
fix some weird PDFs by adding font aliases to the DR dictionary - this is what
I was referring to in my reply from Nov 18. The original version of the
fixFieldFont() method would check if the DR doesn't already contain the font
alias - but if I remove that "if" condition and simply add a new font resource
into the DR dictionary, the issue is gone.
I have updated the CreateVisibleSignature3 example by adding two overloads of
fixFieldFont and added a call to this method to line 582 of testSignPdf(). Now
- once again, I might be doing something completely wrong here (or
overcomplicating things) but 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 be [^CreateVisibleSignature3-update1.zip] tter
way to do it?
The important thing to note here is that I can reproduce the issue (and the
fix) also on a PDF where I do not make the testSetFieldAndFlatten() call and do
not perform partial flattening (but I can't share that file now). I'm not sure
how that document was authored - PDF Producer is "Adobe PDF Library 20.6.66"
and PDF Version is "1.6 (Acrobat 7.x)" - but it may have had other
modifications applied to it as well.
Thank you again for all your help!
> 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]
