[
https://issues.apache.org/jira/browse/PDFBOX-6098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18038425#comment-18038425
]
Radoslav Bielik commented on PDFBOX-6098:
-----------------------------------------
Thank you for your replies Michael and Tilman - sorry I didn't get to test this
earlier.
I have tried to do the incremental save but I'm still getting the first
signature invalidated - the only difference is really that there is a separate
revision with "forms filled in" in the signature panel.
I went through the SVN history between 3.0.2 and 3.0.3 in an attempt to spot
the specific commit that introduced this behavior and it seems to be r1919510
for PDFBOX-5841 _"wrap indirect objects whenever they are added directly to a
COSDictionary or COSArray" -_ this is the first failing one for me (I didn't
test all of them, but the previous one in branches/3.0 - r1919369 - is not
affected and the signature remains valid.
This has changes to cos/COSArray and cos/COSDictionary (and multipdf/Splitter -
possibly unrelated) so I've tried to revert the change to cos/COSDictionary in
pdfbox/tags/3.0.3 and pdfbox/tags/3.0.6 and in both cases, this resulted in
signatures remaining valid.
This is the diff I reverted in cos/COSDictionary - leaving only the "else"
block as in 3.0.2
{code:java}
// wrap indirect objects
if ((value instanceof COSDictionary || value instanceof COSArray)
&& !value.isDirect()
&& value.getKey() != null)
{
COSObject cosObject = new COSObject(value, value.getKey());
items.put(key, cosObject);
getUpdateState().update(cosObject);
}
else
{
items.put(key, value);
getUpdateState().update(value);
}
{code}
I didn't get a chance to read the details of the issue/ticket that introduced
this change so I'm not sure how to proceed at this point? Thank you again!
> 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,
> 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]
