Is this possibly a Document Time Stamp? It needs to be in its own
Incremental Save section (since it needs a hash)
Marc
On 9/2/2025 9:20 AM, Tilman Hausherr wrote:
Am 02.09.2025 um 17:53 schrieb Marc Kaufman:
I don't understand why you are using the byte-range for writing, at
all, except to
Am 02.09.2025 um 17:53 schrieb Marc Kaufman:
I don't understand why you are using the byte-range for writing, at
all, except to insert the signature.
This is done by PDFBox itself, he got an exception in COSWriter.
The mystery is that there seems to be a second "fresh" signature in the
inc
Am 02.09.2025 um 11:41 schrieb Tilman Hausherr:
(So yes I could compare the byte range with
0 10 10 10 to see if it is "our" signature but
I'm not sure if that is the best solution)
To test that, replace the line
if (br2 + br3 > incrementalInput.length())
with
Hi,
I do also not fully understand what's going on. Maybe something in DSS
altering UR3 while doing the signing? All I can say is that there is
this new signature byterange within the incremental part.
If you want to debug PDFBox, concentrate on COSWriter.java and look for
detectPossibleSign
I'm not sure to understand the details. It's seems very subtle.
Does this mean that the new signature is "illegal", breaking the previous ones ?
Should we simply refuse to resign the document certified with UR3 ?
Technically, it does just look like there is not enough space reserved for
writhing
5 matches
Mail list logo