Hi In our case the adding of the new signature is a two step process:
1) The user places his signature image on the document and starts the signature process => at this point we add the signature field at the specified position, we call “saveIncrementalForExternalSigning” and we compute the document Hash that we send to the external signing service. 2) From the external signing service we receive the signature object and eventually the LTV information. We add the signature to the document (pbSigningSupport.setSignature(externalSignature)) and, in case LTV is present after adding it to the document catalog, we call the “saveIncremental” method. Regarding the code segment: In the first step (adding signature field) this segment is reached twice: the first time for the first signature where incrementalUpdate is false, and the second for the new signature field where the doWriteSignature is called. In the second step (where we have the signature content and the LTV info) this segment is reached once, for the old signature, and the method doWriteSignature is called. Thanks a lot and best regards, Patrick > On 26 Sep 2022, at 20:22, Tilman Hausherr <[email protected]> wrote: > > Hi, > > How come that you're reaching something COSWriter before saving? And why are > saveIncrementalForExternalSigning and saveIncremental called? > > Is it because you first have the signature, and then the LTV as an extra step? > > I'm wondering if this code segment > > if (incrementalUpdate) > { > if (signatureOffset == 0 || byteRangeOffset == 0) > { > doWriteIncrement(); > } > else > { > doWriteSignature(); > } > } > > properly distinguishes whether one is signing or doing an incremental saving > without signing anything. Could it be that doWriteSignature is called when it > shouldn't? (Maybe you were saying just that all the time, it's difficult for > me to imagine what happens without the file, despite that you explained a lot) > > Tilman > > On 26.09.2022 09:45, Patrick Herber wrote: >> Thanks a lot for your reply! >> >> I’ve tried to debug as you suggested. >> >> When we “prepare” the document, adding the new signature field before >> calling the “saveIncrementalForExternalSigning” PDDocument’s method, this >> segment is reached twice (first for the old signature and second for the new >> added one). Afterwards the COSWriter “doWriteSignature” (the one that in the >> second “round” will throw the Exception) method is only called once for the >> new signature. >> After the “external” signature is added >> (pbSigningSupport.setSignature(externalSignature)) and the “saveIncremental” >> method is called, this segment is only reached once (for the old signature) >> and so also the "“doWriteSignature” method (always for the old signature). >> Comparing the properties of the old signature between the two calls inside >> this segment for the old signature, I can see that the byteRangeArray, >> byteRangeLength and signatureLength remain unchanged, only the offsets are >> different. Inside the doWriteSignature method then the byteRangeArray object >> is changed with the new offsets and the resulting byteRange String is one >> character longer as it was before and therefore the exception is thrown. >> >> Thanks again and best regards >> >> Patrick >> >> >> >>> On 23 Sep 2022, at 17:37, Tilman Hausherr <[email protected]> wrote: >>> >>> I remember we had this problem before but I can't remember how it was >>> fixed. Currently we consider the first signature we hit. I remember >>> thinking about this and concluding that the algorithm would always hit the >>> first one and not an old one. >>> >>> It's difficult without the file. You'll have to debug this yourself by >>> looking at the reachedSignature field in COSWriter. Maybe the "If we reach >>> the pdf signature" segments are hit twice. If you can build from source, >>> then put debug output in that segment to find out if >>> >>> if(reachedSignature && COSName.BYTERANGE.equals(entry.getKey())) >>> >>> is reached twice. >>> >>> Tilman >>> >>> On 23.09.2022 10:23, Patrick Herber wrote: >>>> Dear PDFBox community >>>> >>>> We use PDFBox (version 2.0.26) for signing documents and we are currently >>>> facing a problem signing a particular document (however, this doesn’t seem >>>> to be an isolated case, since in the past we received the notification of >>>> similar error messages, but we couldn’t have access to the affected >>>> documents). >>>> This document already contains a filled form and a signature (with LTV >>>> support) and when you open the document with Acrobat Reader you get the >>>> message: "This document enabled extended features in Adobe Acrobat Reader. >>>> The document has been changed since it was created and use of extended >>>> features is no longer available. Please contact the author for the >>>> original version of this document.” >>>> >>>> Now, when we try to sign it, also using an LTV-enabled signature (Advanced >>>> or Qualified), we receive following error message: >>>> >>>> java.io.IOException: Can't write new byteRange '0 542575 554377 7562]' not >>>> enough space: byteRange.length(): 21, byteRangeLength: 20 >>>> at >>>> org.apache.pdfbox.pdfwriter.COSWriter.doWriteSignature(COSWriter.java:763) >>>> at >>>> org.apache.pdfbox.pdfwriter.COSWriter.visitFromDocument(COSWriter.java:1199) >>>> at org.apache.pdfbox.cos.COSDocument.accept(COSDocument.java:452) >>>> at org.apache.pdfbox.pdfwriter.COSWriter.write(COSWriter.java:1435) >>>> at >>>> org.apache.pdfbox.pdmodel.PDDocument.saveIncremental(PDDocument.java:1412) >>>> at >>>> com.swisscom.ais.client.impl.PdfDocument.finishSignature(PdfDocument.java:180) >>>> ... 4 more >>>> >>>> Instead adding a simple timestamp (without LTV) it works without issues. >>>> >>>> The byteRange length referred in the stack trace is the one of the OLD >>>> signature and not of the one we are adding to the document (please note >>>> that for the new one we reserve a size of 30’000 bytes, and also >>>> increasing this size has no impact). >>>> >>>> Unfortunately I’m not allowed to share with you this document (I’m trying >>>> to arrange the creation of a new sample document with the same properties, >>>> but the author of the file is currently in holiday). >>>> >>>> In the PDFBox Jira I’ve found some already solved issues regarding >>>> saveIncremental and these “extended features”: >>>> >>>> https://issues.apache.org/jira/browse/PDFBOX-45 >>>> https://issues.apache.org/jira/browse/PDFBOX-2857 >>>> https://issues.apache.org/jira/browse/PDFBOX-2858 >>>> https://issues.apache.org/jira/browse/PDFBOX-2859 >>>> In one of these issues (PDFBOX-2858), I found a file example >>>> (santander_freistellungsauftrag_modified.pdf >>>> <https://issues.apache.org/jira/secure/attachment/12744154/santander_freistellungsauftrag_modified.pdf >>>> >>>> <https://issues.apache.org/jira/secure/attachment/12744154/santander_freistellungsauftrag_modified.pdf>>). >>>> I’ve try to sign it (and also countersign it) but “unfortunately” also >>>> this one worked without any issue. >>>> >>>> Can you kindly help me solving this problem? >>>> >>>> Thanks and best regards, >>>> >>>> Patrick >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> <mailto:[email protected]> >>> For additional commands, e-mail: [email protected] >>> <mailto:[email protected]> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
