Hi Tilman
The signing of this document works without problems.
During the signing process of “my” document I have these values:
First step:
Old signature:
byteRangeArray: COSArray{[COSInt{0}, COSInt{1510}, COSInt{13312},
COSInt{382555}]}
byteRangeOffset: 480058
New signature:
byteRangeArray: COSArray{[COSInt{0}, COSInt{1000000000}, COSInt{1000000000},
COSInt{1000000000}]}
byteRangeOffset: 541861
Second step:
byteRangeArray: COSArray{[COSInt{0}, COSInt{1510}, COSInt{13312},
COSInt{382555}]} => same as in the first step
byteRangeOffset: 560579
=> different
(Please note that the signatureLength remains the same 11802)
During the doWriteSignature the byteRangeArray is then changed to:
COSArray{[COSInt{0}, COSInt{548764}, COSInt{560566}, COSInt{7646}]}
There we have these variable values:
inLength 548646
beforeLength 548764
afterOffset 560566
afterLength 7646
getStandardOutput().getPos() 568212
signatureOffset 548764
signatureLength 11802
> Could it be that when doing an incremental save, somehow the old signature
> ends up being part of the incremental save (which shouldn't happen)?
This seams to be the case… perhaps because adding the LTV information to the
document catalog the old signature changes its “position” inside the document…
Can I give you further information?
Thanks again and best regards,
Patrick
> On 27 Sep 2022, at 05:07, Tilman Hausherr <[email protected]> wrote:
>
> Does it happen with this file?
>
> https://www.quovadisglobal.com/wp-content/uploads/2020/01/QV_RCA1_RCA3_CPCPS_V4_11.pdf
>
> Btw what is byteRangeOffset when calling doWriteSignature() ? In theory this
> should be the beginning of the actual byte range in the (not yet existing)
> final PDF. So if this value is smaller than incrementalInput.length() then it
> would also mean this is wrong. OTOH how could this ever be smaller when doing
> an incremental write?! Could it be that when doing an incremental save,
> somehow the old signature ends up being part of the incremental save (which
> shouldn't happen)?
>
> Another thought: add this
>
> System.out.println("/ByteRange array: " + value);
>
> in this segment
>
> else if(reachedSignature && COSName.BYTERANGE.equals(entry.getKey()))
>
> the output should always be
>
> COSArray{[COSInt{0}, COSInt{1000000000}, COSInt{1000000000},
> COSInt{1000000000}]}
>
> Tilman
>
> On 26.09.2022 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]
>>>
>
>
> ---------------------------------------------------------------------
> 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]
