Hi Maruan Yes, you are right: the document is already signed (with LTV) and when I open it with Acrobat Reader I receive the warning message. The error occurs when I try to add a second signature to it (also with LTV => adding a simple Timestamp (without LTV) works fine).
I’m sorry that I can’t provide the document (the one I have contains confidential information): I’m trying to organise the creation of a test document, but I need to wait for the author of the document, who is currently in holiday… Thanks a lot and best regards Patrick > On 26 Sep 2022, at 20:37, [email protected] wrote: > > > Hi, > > do I understand it correctly that you get an already signed document > which when opened causes the Adobe Reader message? > > You are trying to sign that document a second time? > > If you can't provide such a document for testing (which would be the > best option) I can propably generate such a sample document. > > BR > Maruan > > > > Am Montag, dem 26.09.2022 um 20:22 +0200 schrieb Tilman Hausherr: >> 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(COSWrite >>>>> r.java:763) >>>>> at >>>>> org.apache.pdfbox.pdfwriter.COSWriter.visitFromDocument(COSWrit >>>>> er.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(PdfDoc >>>>> ument.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/sant >>>>> ander_freistellungsauftrag_modified.pdf < >>>>> https://issues.apache.org/jira/secure/attachment/12744154/santa >>>>> nder_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] >> > > -- > -- > Maruan Sahyoun > > FileAffairs GmbH > Josef-Schappe-Straße 21 > 40882 Ratingen > > Tel: +49 (2102) 89497 88 > Fax: +49 (2102) 89497 91 > [email protected] > www.fileaffairs.de > > Geschäftsführer: Maruan Sahyoun > Handelsregister: AG Düsseldorf, HRB 53837 > UST.-ID: DE248275827 > > --------------------------------------------------------------------- > 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]
