You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@pdfbox.apache.org by Patrick Herber <pa...@gmail.com> on 2022/09/23 08:23:54 UTC
Problem signing (with LTV) an already signed document with extended features enabled
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>). 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
Re: Problem signing (with LTV) an already signed document with extended features enabled
Posted by Patrick Herber <pa...@gmail.com>.
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, sahyoun@fileaffairs.de 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 <TH...@t-online.de>
>>>> 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:
>>>> users-unsubscribe@pdfbox.apache.org <mailto:
>>>> users-unsubscribe@pdfbox.apache.org>
>>>> For additional commands, e-mail:
>>>> users-help@pdfbox.apache.org <mailto:
>>>> users-help@pdfbox.apache.org>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>
>
> --
> --
> Maruan Sahyoun
>
> FileAffairs GmbH
> Josef-Schappe-Straße 21
> 40882 Ratingen
>
> Tel: +49 (2102) 89497 88
> Fax: +49 (2102) 89497 91
> sahyoun@fileaffairs.de
> www.fileaffairs.de
>
> Geschäftsführer: Maruan Sahyoun
> Handelsregister: AG Düsseldorf, HRB 53837
> UST.-ID: DE248275827
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Problem signing (with LTV) an already signed document with extended features enabled
Posted by Patrick Herber <pa...@gmail.com>.
Thanks a lot for your great support!
Best regards
Patrick
> On 29 Sep 2022, at 20:35, Tilman Hausherr <TH...@t-online.de> wrote:
>
> On 28.09.2022 19:08, Tilman Hausherr wrote:
>> https://issues.apache.org/jira/browse/PDFBOX-5521
>
>
> Snapshot build available here:
>
> https://repository.apache.org/content/groups/snapshots/org/apache/pdfbox/pdfbox-app/2.0.28-SNAPSHOT/
>
> it's mostly the code I posted, with some fine-tuning.
>
> Tilman
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Problem signing (with LTV) an already signed document with extended features enabled
Posted by Tilman Hausherr <TH...@t-online.de>.
On 28.09.2022 19:08, Tilman Hausherr wrote:
> https://issues.apache.org/jira/browse/PDFBOX-5521
Snapshot build available here:
https://repository.apache.org/content/groups/snapshots/org/apache/pdfbox/pdfbox-app/2.0.28-SNAPSHOT/
it's mostly the code I posted, with some fine-tuning.
Tilman
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Problem signing (with LTV) an already signed document with extended features enabled
Posted by Tilman Hausherr <TH...@t-online.de>.
https://issues.apache.org/jira/browse/PDFBOX-5521
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Problem signing (with LTV) an already signed document with extended features enabled
Posted by Tilman Hausherr <TH...@t-online.de>.
Hi,
Thanks for the feedback, and for your patience and support. I'm waiting
for the 2.0.27 vote to end and then I will commit the change, so it will
be in 2.0.28 (in several months).
The code was written at a moment when I was fully awake and very
focused, so it's probably good 😆 (all other comments here were written
when I wasn't fully awake yet, or tired).
What remains is the question why this old signature is in the
incremental save. I'll play around with the "quo vadis" file I
mentioned, i.e. trying to sign it to see what happens.
Maybe it's because of "fieldArray.setNeedToBeUpdated(true)" in
PDDocument.java, the classic incremental save requests that there be a
"update path" towards each item that should be updated, so maybe all top
fields gets updated.
Tilman
On 27.09.2022 10:13, Patrick Herber wrote:
> Hi Tilman
>
> I’ve tried to compile the source with this change and sign “my” document and it works fine! The document is signed and both signature appears as valid in Acrobat.
> Also countersigning the sample file you sent me continues to work well!
> Thanks a lot! Do you think this is a fix we can keep or would it be better to perform an additional analysis?
>
> Best regards,
> Patrick
>
>
>
>> On 27 Sep 2022, at 08:44, Tilman Hausherr <TH...@t-online.de> wrote:
>>
>> Here's some quick code, replace the beginning of the method "visitFromDictionary(COSDictionary obj)" with it
>>
>> if (!reachedSignature && incrementalUpdate)
>> {
>> COSBase itemType = obj.getItem(COSName.TYPE);
>> if (COSName.SIG.equals(itemType) || COSName.DOC_TIME_STAMP.equals(itemType))
>> {
>> COSArray byteRange = obj.getCOSArray(COSName.BYTERANGE);
>> if (byteRange != null && byteRange.size() == 4)
>> {
>> COSBase base2 = byteRange.getObject(2);
>> COSBase base3 = byteRange.getObject(3);
>> if (base2 instanceof COSInteger && base3 instanceof COSInteger)
>> {
>> long br2 = ((COSInteger) base2).longValue();
>> long br3 = ((COSInteger) base3).longValue();
>> if (br2 + br3 > incrementalInput.length())
>> {
>> reachedSignature = true;
>> }
>> else
>> {
>> //TODO log warning
>> }
>> }
>> }
>> }
>> }
>>
>> Tilman
>>
>>
>> On 27.09.2022 08:27, Tilman Hausherr wrote:
>>> I'm thinking of adding some code that checks whether it is an "old" signature by comparing it to these huge values that we use (or better, by comparing value[2] + value[3] to the length of the input file). This would then skip these old signatures. Best place would be the segment where "reachedSignature = true" is hit. And also add a warning when we encounter such old signatures, as this shouldn't happen in incremental save.
>>>
>>> Tilman
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Problem signing (with LTV) an already signed document with extended features enabled
Posted by Patrick Herber <pa...@gmail.com>.
Hi Tilman
I’ve tried to compile the source with this change and sign “my” document and it works fine! The document is signed and both signature appears as valid in Acrobat.
Also countersigning the sample file you sent me continues to work well!
Thanks a lot! Do you think this is a fix we can keep or would it be better to perform an additional analysis?
Best regards,
Patrick
> On 27 Sep 2022, at 08:44, Tilman Hausherr <TH...@t-online.de> wrote:
>
> Here's some quick code, replace the beginning of the method "visitFromDictionary(COSDictionary obj)" with it
>
> if (!reachedSignature && incrementalUpdate)
> {
> COSBase itemType = obj.getItem(COSName.TYPE);
> if (COSName.SIG.equals(itemType) || COSName.DOC_TIME_STAMP.equals(itemType))
> {
> COSArray byteRange = obj.getCOSArray(COSName.BYTERANGE);
> if (byteRange != null && byteRange.size() == 4)
> {
> COSBase base2 = byteRange.getObject(2);
> COSBase base3 = byteRange.getObject(3);
> if (base2 instanceof COSInteger && base3 instanceof COSInteger)
> {
> long br2 = ((COSInteger) base2).longValue();
> long br3 = ((COSInteger) base3).longValue();
> if (br2 + br3 > incrementalInput.length())
> {
> reachedSignature = true;
> }
> else
> {
> //TODO log warning
> }
> }
> }
> }
> }
>
> Tilman
>
>
> On 27.09.2022 08:27, Tilman Hausherr wrote:
>> I'm thinking of adding some code that checks whether it is an "old" signature by comparing it to these huge values that we use (or better, by comparing value[2] + value[3] to the length of the input file). This would then skip these old signatures. Best place would be the segment where "reachedSignature = true" is hit. And also add a warning when we encounter such old signatures, as this shouldn't happen in incremental save.
>>
>> Tilman
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Problem signing (with LTV) an already signed document with extended features enabled
Posted by Tilman Hausherr <TH...@t-online.de>.
Here's some quick code, replace the beginning of the method
"visitFromDictionary(COSDictionary obj)" with it
if (!reachedSignature && incrementalUpdate)
{
COSBase itemType = obj.getItem(COSName.TYPE);
if (COSName.SIG.equals(itemType) ||
COSName.DOC_TIME_STAMP.equals(itemType))
{
COSArray byteRange = obj.getCOSArray(COSName.BYTERANGE);
if (byteRange != null && byteRange.size() == 4)
{
COSBase base2 = byteRange.getObject(2);
COSBase base3 = byteRange.getObject(3);
if (base2 instanceof COSInteger && base3 instanceof COSInteger)
{
long br2 = ((COSInteger) base2).longValue();
long br3 = ((COSInteger) base3).longValue();
if (br2 + br3 > incrementalInput.length())
{
reachedSignature = true;
}
else
{
//TODO log warning
}
}
}
}
}
Tilman
On 27.09.2022 08:27, Tilman Hausherr wrote:
> I'm thinking of adding some code that checks whether it is an "old"
> signature by comparing it to these huge values that we use (or better,
> by comparing value[2] + value[3] to the length of the input file).
> This would then skip these old signatures. Best place would be the
> segment where "reachedSignature = true" is hit. And also add a warning
> when we encounter such old signatures, as this shouldn't happen in
> incremental save.
>
> Tilman
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Problem signing (with LTV) an already signed document with extended features enabled
Posted by Tilman Hausherr <TH...@t-online.de>.
I'm thinking of adding some code that checks whether it is an "old"
signature by comparing it to these huge values that we use (or better,
by comparing value[2] + value[3] to the length of the input file). This
would then skip these old signatures. Best place would be the segment
where "reachedSignature = true" is hit. And also add a warning when we
encounter such old signatures, as this shouldn't happen in incremental save.
Tilman
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Problem signing (with LTV) an already signed document with extended features enabled
Posted by Patrick Herber <pa...@gmail.com>.
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 <TH...@t-online.de> 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, sahyoun@fileaffairs.de 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 <TH...@t-online.de>
>>>>> 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:
>>>>> users-unsubscribe@pdfbox.apache.org <mailto:
>>>>> users-unsubscribe@pdfbox.apache.org>
>>>>> For additional commands, e-mail:
>>>>> users-help@pdfbox.apache.org <mailto:
>>>>> users-help@pdfbox.apache.org>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Problem signing (with LTV) an already signed document with extended features enabled
Posted by Tilman Hausherr <TH...@t-online.de>.
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, sahyoun@fileaffairs.de 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 <TH...@t-online.de>
>>>> 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:
>>>> users-unsubscribe@pdfbox.apache.org <mailto:
>>>> users-unsubscribe@pdfbox.apache.org>
>>>> For additional commands, e-mail:
>>>> users-help@pdfbox.apache.org <mailto:
>>>> users-help@pdfbox.apache.org>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Problem signing (with LTV) an already signed document with extended features enabled
Posted by "sahyoun@fileaffairs.de" <sa...@fileaffairs.de>.
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 <TH...@t-online.de>
> > > 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:
> > > users-unsubscribe@pdfbox.apache.org <mailto:
> > > users-unsubscribe@pdfbox.apache.org>
> > > For additional commands, e-mail:
> > > users-help@pdfbox.apache.org <mailto:
> > > users-help@pdfbox.apache.org>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>
--
--
Maruan Sahyoun
FileAffairs GmbH
Josef-Schappe-Straße 21
40882 Ratingen
Tel: +49 (2102) 89497 88
Fax: +49 (2102) 89497 91
sahyoun@fileaffairs.de
www.fileaffairs.de
Geschäftsführer: Maruan Sahyoun
Handelsregister: AG Düsseldorf, HRB 53837
UST.-ID: DE248275827
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Problem signing (with LTV) an already signed document with extended features enabled
Posted by Patrick Herber <pa...@gmail.com>.
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 <TH...@t-online.de> 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 <TH...@t-online.de> 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: users-unsubscribe@pdfbox.apache.org <ma...@pdfbox.apache.org>
>>> For additional commands, e-mail: users-help@pdfbox.apache.org <ma...@pdfbox.apache.org>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Problem signing (with LTV) an already signed document with extended features enabled
Posted by Tilman Hausherr <TH...@t-online.de>.
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 <TH...@t-online.de> 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: users-unsubscribe@pdfbox.apache.org <ma...@pdfbox.apache.org>
>> For additional commands, e-mail: users-help@pdfbox.apache.org <ma...@pdfbox.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Problem signing (with LTV) an already signed document with extended features enabled
Posted by Patrick Herber <pa...@gmail.com>.
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 <TH...@t-online.de> 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: users-unsubscribe@pdfbox.apache.org <ma...@pdfbox.apache.org>
> For additional commands, e-mail: users-help@pdfbox.apache.org <ma...@pdfbox.apache.org>
Re: Problem signing (with LTV) an already signed document with extended features enabled
Posted by Tilman Hausherr <TH...@t-online.de>.
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>). 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: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org