[ 
https://issues.apache.org/jira/browse/PDFBOX-5139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17308692#comment-17308692
 ] 

Michael Klink edited comment on PDFBOX-5139 at 3/25/21, 1:57 PM:
-----------------------------------------------------------------

{quote}1) The 1.4 and 1.6 original pdfs are not broken?
{quote}
At least their cross reference tables or not segmented. I haven't looked for 
other issues yet.

As [~tilman] already hinted at, though, there are disallowed trailer entries. 
Such disallowed entries actually can be found in all originals except the 1.6 
one.
{quote}2) How itext manages to do a valid signature. Do they "fix" the pdf?
{quote}
With iText you applied only the second signature in append mode, i.e. in an 
incremental update, so iText stored the revision with the first signature 
completely anew creating new cross reference tables, so the bug in your 
original file was fixed.

PDFBox, on the other hand, out of the box only supports signing in incremental 
updates, so with PDFBox you both times signed in incremental updates, so the 
original document revision with its bug remained.

One can call this an iText feature. On the other hand one can also consider it 
a mis-feature: Signing after all shall attest the document it was given, but 
repairs _change_ what was given.


was (Author: mkl):
{quote}1) The 1.4 and 1.6 original pdfs are not broken?
{quote}
At least their cross reference tables or not segmented. I haven't looked for 
other issues yet.
{quote}2) How itext manages to do a valid signature. Do they "fix" the pdf?
{quote}
With iText you applied only the second signature in append mode, i.e. in an 
incremental update, so iText stored the revision with the first signature 
completely anew creating new cross reference tables, so the bug in your 
original file was fixed.

PDFBox, on the other hand, out of the box only supports signing in incremental 
updates, so with PDFBox you both times signed in incremental updates, so the 
original document revision with its bug remained.

One can call this an iText feature. On the other hand one can also consider it 
a mis-feature: Signing after all shall attest the document it was given, but 
repairs _change_ what was given.

> Signing PDF with empty fields multiple times breaks signature
> -------------------------------------------------------------
>
>                 Key: PDFBOX-5139
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-5139
>             Project: PDFBox
>          Issue Type: Bug
>    Affects Versions: 2.0.23
>            Reporter: Fabricio
>            Priority: Major
>         Attachments: 1.4.pdf, 1.4.signed.signed.pdf, 
> 1.5.itext.signed.signed.pdf, 1.5.pdf, 1.5.signed.signed.pdf, 1.6.pdf, 
> 1.6.signed.signed.pdf, 1.7.itext.signed.signed.pdf, 1.7.pdf, 
> 1.7.signed.signed.pdf
>
>
> Hi!
> I apologize if there is already a similar report.
> We have a PDF document with multiple empty signature fields. We are currently 
> preparing the document and adding the fields with the javascript library 
> PSPDFKit.
> Our signature implementation with PDFBOX is based on 
> [https://apache.googlesource.com/pdfbox/+/trunk/examples/src/main/java/org/apache/pdfbox/examples/signature/CreateVisibleSignature2.java]
> When signing the document more than one time, the first signature is 
> invalidated for some PDF Spec versions. We tried adding the new signatures in 
> the existing fields, and in new ones, but the results is the same.
> The multiple signature works well with PDF versions 1.4 and 1.6. It does not 
> work with versions 1.5 and 1.7. The first signature is invalidated by the 
> second one.
> Initially, I had the doubt if this problem was related to PSDPFKit or 
> PDF-Box. While investigating, we tried to sign the 1.5 spec version document 
> multiple times using iText and it worked ok.
> I'm attaching 10 pdfs:
>  * For each spec version, one PDF with the empty signature fields, and 
> another one with 2 signatures made by Apache PDF-Box.
>  * Specs 1.5 and 1.7 signed 2 times by itext.
> Thank you for your help.
> Fabricio
> Edit 1: We are not using the certify functionality 
> (SigUtils.setMDPPermission).
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to