I don't have a test fie in front of me, but let me make a couple of
conjectures. First, the digital signature system in PDF is indeed
complicated. Each signature covers the entire file, minus the "hole" for
the signature itself. To do that, one must first save the file, then
compute the hash over all the bytes (including previous signatures) to
the end of file, excluding the space for the current signature.
You can't write the byte-range values until you have saved the file,
because it's not until then that you know where the %%EOF is. Then you
write the byte-range values, then you take the hash, then create the
signature, then write it into the reserved space without modifying any
other bytes. This is done by overwriting the signature area in the file,
NOT by copying the file or re-saving it.
I don't understand why you are using the byte-range for writing, at all,
except to insert the signature.
In a file with a UR3 signature, it's possible to think that there is no
signature since it doesn't show up in the AcroForm area. Are you doing a
Full Save for the new signature when an Incremental Save is called for?
Marc
On 9/2/2025 2:20 AM, Coetmeur, Alain wrote:
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 the string for the ByteRange directive.
I thought it was just a problem of 20 bytes instead of 22 bytes ...
PDF format is very complex.
We are trying to reproduce problem, but we don't yet understand what the client
did with the form.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: users-h...@pdfbox.apache.org
