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
detectPossibleSignature(). I added a debug log output yesterday. Change
the log level to debug. Normally the output should be like this:
pdfwriter.COSWriter:1302 - reachedSignature at offset nnnnn, byteRange:
COSArray{[COSInt{0}, COSInt{1000000000}, COSInt{1000000000},
COSInt{1000000000}]}
(So yes I could compare the byte range with
0 1000000000 1000000000 1000000000 to see if it is "our" signature but
I'm not sure if that is the best solution)
This is because the signing process puts a placeholder byterange that is
very large. The offset is later overwritten with the actual data (in
doWriteSignature()), because we don't know the exact length at the time
of writing.
You could add logging "obj" to see what's in the "wrong" signature, some
applications put details, here's from the Santander file, which shows
the date and the application:
The software takes care not to touch old signatures since
https://issues.apache.org/jira/browse/PDFBOX-5521
It is ok to sign a document that has UR3, I did it myself with that
Santander file.
Tilman
Am 02.09.2025 um 11:20 schrieb Coetmeur, Alain:
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.
I will clone pdfbox to test the sample, and some ideas.
Thanks for your advices.
Alain COETMEUR
Interne
-----Message d'origine-----
De : Marc Kaufman<[email protected]>
Envoyé : lundi 1 septembre 2025 18:03
À :[email protected]
Objet : Re: Error "Can't write new byteRange … not enough space…" signing with
PADES a document having user's rights protected by Perms/UR3
[EMETTEUR EXTERNE] : Soyez vigilant avant d’ouvrir les pièces-jointes ou de
cliquer sur les liens. En cas de doute, signalez le message via le bouton «
Signaler un courriel suspect ».
When validating signatures (including the UR3 signature) it is necessary to
confirm that the byte range ends just past an instance of %%EOF. Any byte
range that is longer than the file is an indication that someone did a Full
Save (rather than an Incremental Save) some time after the first signing. If
you insist on proceeding, you should ignore all invalid signatures.
Note that a signature can be deleted, which is indicated by that signature
widget not appearing in the latest AcroForm/Fields array.
That's OK, but don't consider it for DSS. There is no requirement that signatures appear
"in order" in the Fields array. If you must order the signatures, do it in
order of increasing last byte, as that indicates the order of incremental saves.
Marc
On 9/1/2025 5:53 AM, Tilman Hausherr wrote:
Sadly, the length 144951 does NOT confirm what I expected. The "bad"
byte range (offset1 len1 offset2 len2) is [0 1569 11103 160382], so
the second segment is longer than the original file. This means that
this isn't an "old" value, it was created at some time during the
signing process. The code has "if (br2 + br3 >
incrementalInput.length())" which avoids messing with old signatures.
What happens if you don't use DSS to sign, but the CreateSignature
example of PDFBox?
Tilman
---------------------------------------------------------------------
To unsubscribe, e-mail:[email protected]
For additional commands, e-mail:[email protected]
Ce message et toutes les pièces jointes (ci-après le «message») sont
confidentiels et établis à l’intention exclusive de ses destinataires. Toute
utilisation de ce message non conforme à sa destination, toute diffusion ou
toute publication, totale ou partielle, est interdite, sauf autorisation
expresse. Si vous recevez ce message par erreur, merci de le détruire sans en
conserver de copie et d’en avertir immédiatement l’expéditeur. Internet ne
permettant pas de garantir l’intégrité de ce message, la Caisse des Dépôts et
Consignations décline toute responsabilité au titre de ce message s’il a été
modifié, altéré, déformé ou falsifié. Par ailleurs et malgré toutes les
précautions prises pour éviter la présence de virus dans nos envois, nous vous
recommandons de prendre, de votre côté, les mesures permettant d'assurer la
non-introduction de virus dans votre système informatique. This email message
and any attachments (“the email”) are confidential and intended only for the
recipient(s) indicated. If you are not an intended recipient, please be advised
that any use, dissemination, forwarding or copying of this email whatsoever is
prohibited without prior written consent of Caisse des Depots et Consignations.
If you have received this email in error, please delete it without saving a
copy and notify the sender immediately. Internet emails are not necessarily
secure, and Caisse des Depots et Consignations declines responsibility for any
changes that may have been made to this email after it was sent. While we take
all reasonable precautions to ensure that viruses are not transmitted via
emails, we recommend that you take your own measures to prevent viruses from
entering your computer system.
---------------------------------------------------------------------
To unsubscribe, e-mail:[email protected]
For additional commands, e-mail:[email protected]
