TL;DR:
I've found that the problem is that in the writeSignature()
it is the Perms/UR3 signature, which is updated, not the PADES
Acroform/Fields[0]/V as it should.
I don't master the code, so I don't understand why.
Maybe you can understand ?
Details:
I have tested my bruteforce patch, just preventing the exception,
in org.apache.pdfbox.pdfwriter.COSWriter.doWriteSignature()
if (byteRange.length() > byteRangeLength)
{
// fixme get around problem
System.err.printf("Longer ByteRange : '%s' not enough space: %d >
%d ; byteRangeOffset=%s %n",byteRange,byteRange.length() ,
byteRangeLength,byteRangeOffset);
byteRangeLength=byteRange.length();
// throw new IOException("Can't write new byteRange '" + byteRange +
// "' not enough space: byteRange.length(): " +
byteRange.length() +
// ", byteRangeLength: " + byteRangeLength +
// ", byteRangeOffset: " + byteRangeOffset);
}
and I get a signed document (the signature is however invalid)
with pdfbox-app debug now I realize the ByteRange are wrong.
It seems the Perms/UR2 have been changed,
From 0 1569 11103 160382
To 0 145478 164424 26017
and the AcroForm/Fields[0]/V is the default huge value
0 1000000000 1000000000 1000000000
here is the capture of the wrongly signed file using my patched pdfbox4
https://ibb.co/nMB17TGt
the initial file produce this capture
https://ibb.co/848FvxHF
so the exception is probably because UR3 signature is edited, not the PADES
Acroform/Fields.
when signed with DSS6.1/pdfbox2, the Perms/UR2 ByteRange is conserved
https://ibb.co/0VKSpV8B
0 1569 11103 160382
I've checked the document at runtime in the PDDocument.saveIncremental, up to
the doWriteSignature, and the Perms/UR3 ByteRange seems conserved in the
pdDocument.documentcatalog.root
the trace I've added show that visitFromDictionary sees first the PADES new
signature, then the Perms/UR3 old signature
DEBUGTRACE: visitFromDictionary on BYTERANGE=COSArray{[COSInt{0},
COSInt{1000000000}, COSInt{1000000000}, COSInt{1000000000}]}
DEBUGTRACE: visitFromDictionary previous byteRangeLength=0 byteRangeLengthNow=35
DEBUGTRACE: visitFromDictionary after byteRangeLength=35
DEBUGTRACE: visitFromDictionary on BYTERANGE=COSArray{[COSInt{0}, COSInt{1569},
COSInt{11103}, COSInt{160382}]}
DEBUGTRACE: visitFromDictionary previous byteRangeLength=35
byteRangeLengthNow=20
DEBUGTRACE: visitFromDictionary after byteRangeLength=20
DEBUGTRACE: doWriteSignature beforeLength=145478 afterOffset=164424
afterLength=26017
So clearly it seems that in doWriteSignature, it's the Perms/UR3 which is
written, not the AcroForm/Field/V as expected.
It explains why the huge default ByteRange is kept in Acroform/Fields, and why
Perms/UR3 ByteRange is modified, breaking the previous signature.
I don't master the code, so I don't understand what to correct.
Alain COETMEUR
DIL - Pôle Fondations – Expert Confiance Numérique
Network 2 - 3e étage aile C - 18 avenue Aristide Briand – 92220 Bagneux - France
Mobile +33 6 74 17 42 58
[email protected]
Interne
-----Message d'origine-----
De : Coetmeur, Alain
Envoyé : mercredi 17 septembre 2025 08:56
À : [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
Thnaks you all for the explanatios...
It seems the document is old, using ARE mechanism that is obsolete, and that
strangely the signature is added inside the initial ByteRange...
It's abnormal.
here are the image of the pdfbox-app debug https://ibb.co/848FvxHF
https://ibb.co/0VKSpV8B
Alain COETMEUR
DIL - Pôle Fondations – Expert Confiance Numérique Network 2 - 3e étage aile C
- 18 avenue Aristide Briand – 92220 Bagneux - France Mobile +33 6 74 17 42 58
[email protected]
-----Message d'origine-----
De : Tilman Hausherr <[email protected]> Envoyé : mardi 16 septembre 2025 19:48 À :
[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 ».
Your screenshots didn't get through. This works with Thunderbird but not with
other mail software that doesn't do real inline images. You'd have to upload to
a sharehoster.
Even then, I doubt I will have any solution based on these screenshots because
these won't answer the problem / suspicion I mentioned.
Yes this UR3 thing is an Adobe feature (but then, whole PDF is).
Incremental saving means that the original PDF stays like it is, but that new
data is appended at the end of the file. That's why I was surprised that the
byte range of that UR3 signature was within the incremental segment, instead of
being in the original segment only.
(post 01.09.2025, 14:53)
Tilman
Am 16.09.2025 um 19:09 schrieb Coetmeur, Alain:
I have used PDFBOX-app 4.0.0 debug and this clarify the structure...
Here is attached the capture of the tree for internal data for the
document before signing with DSS as PADES
the signature in "Perms/UR3/Contents" is PKCS7 signed data, signed by
this certificate CN=ARE Acrobat Product v8.0 P23 0002337 OU=Adobe
Trust Services O=Adobe Systems Incorporated C=US
Maybe you will understand the purpose of that Perms/UR3 signature ?
It seems to be an Adobe functionality.
I cannot debug the result since the Pades signature fails and returns nothing.
However, I have signed with the older DSS, using PDFBOX2.x, which
works well and here is the capture of the tree of the resigned in
PADES document
the problem seems to be that the ByteRange are slightly different, and the
difference lead to a difference in the number of digits, thus the length of the
field.
What I don't understand is why when I try to force the maximum length for
ByteRange field for the Acroform/Field/0/V, it breaks the Perms/UR3 signing.
But I don't understand what is the incremental saving... PDF is very subtle.
Alain
---------------------------------------------------------------------
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]
