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 <thaush...@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-unsubscr...@pdfbox.apache.org
<mailto:users-unsubscr...@pdfbox.apache.org>
For additional commands, e-mail: users-h...@pdfbox.apache.org
<mailto:users-h...@pdfbox.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: users-h...@pdfbox.apache.org
