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]
