Attachment damages signature

Question

I have PDF document.

1) Adobe reader reads document well.

2) I sign document (using pdfbox) and everything is well

3) I try to attach file to original pdf (Code is written in the pdfbox web page - in the cookBook).

4) Adobe reader reads attached document well. everything is well.

5) Now I have document with attachment.

6) I try to sign that document (I mean document with attachment). And I have 2 problem:

First: when I open document, Adobe reader tells me that signature byte range is invalid.

Second: when I try to close document (I mean to close adobe reader), Adobe reader tells me that: Do you want to save changes to "original[with-attachment][signed]" before closing? I didn't find thy this happens.

here is testing files uploaded to the google doc

Answer 1

The cause of your issue is that the process of signing original[with-attachment].pdf creates an incremental update with a cross reference stream while the source file has a cross reference table. When adding incremental updates, the new cross references must be of the same type as the old ones.

It is quite possible that this error is due to the process attaching attach.txt misbehaving a bit, too: it stores the file as a PDF with a cross reference table even though the original was a file with a cross reference stream, but at the same time leaves some elements from the former cross reference dictionary in the trailer of the new file. These left-over elements (which do not belong in a trailer dictionary) probably make your signing process think the source already uses a cross reference stream.

As this change of cross reference style between incremental updates is forbidden, the Adobe Reader tries to fix the document in memory. Such attempts to fix often give rise to unexpected Do you want to save changes to "original[with-attachment][signed]" before closing? warnings.

In the course of fixing the PDF, the whole PDF is rearranged. This obviously causes that signature byte range is invalid.

original.pdf

%PDF-1.3
%âãÏÓ
11 0 obj
<</Linearized 1/L 48987/O 13/E 37674/N 3/T 48682/H [ 480 178]>>
endobj
25 0 obj
<</DecodeParms<</Columns 4/Predictor 12>>/Filter/FlateDecode/ID[<321A6D6DCD0785E8E35BD4B13115140A><59793561FB914D408936FC170763541A>]/Index[11 22]/Info 10 0 R/Length 77/Prev 48683/Root 12 0 R/Size 33/Type/XRef/W[1 2 1]>>stream
hÞbbd``b`jŒ â`–,õ@‚µÄb‰í±@Ä"Q{$¬rÄ‚MLŒ³€,F¬ÄÆK¿ Mi
endstream
endobj
startxref
0
%%EOF

32 0 obj 

[.........]

endobj
8 0 obj
<</DecodeParms<</Columns 3/Predictor 12>>/Filter/FlateDecode/ID[<321A6D6DCD0785E8E35BD4B13115140A><59793561FB914D408936FC170763541A>]/Info 10 0 R/Length 50/Root 12 0 R/Size 11/Type/XRef/W[1 2 0]>>stream
hÞbb```bœ¬ÅÄÀ°“‰A\š‰H³Îbbà)²'ñ5&F§Û@yF€  xi 
endstream
endobj
startxref
116
%%EOF

original[with-attachment].pdf

%PDF-1.3
%öäüß
1 0 obj

[.........]

endobj
xref
0 33 
0000000000 65535 f
0000000015 00000 n
[...]
0000049667 00000 n
0000049737 00000 n
trailer
<<
/DecodeParms <<
/Columns 4
/Predictor 12
>>
/Filter /FlateDecode
/ID [<321A6D6DCD0785E8E35BD4B13115140A> <59793561FB914D408936FC170763541A>]
/Info 5 0 R
/Length 77
/Root 1 0 R
/Size 33
/Type /XRef
/W [1 2 1]
/Index [11 22]
>>
startxref
49755
%%EOF 

original[with-attachment][signed].pdf

%PDF-1.3
%öäüß
1 0 obj

[....as above....]

startxref
49755
%%EOF 

1 0 obj

[.........]

endobj
37 0 obj
<<
/ID [<DC60F4419C05967B81D7F64090027D7F> <DC60F4419C05967B81D7F64090027D7F>]
/Info 5 0 R
/Root 1 0 R
/Prev 49755
/Type /XRef
/Size 38
/Filter /FlateDecode
/Index [1 1 6 1 33 4]
/W [1 3 0]
/Length 31
>>
stream
xœcd8ú‘1&ˆ‘áØ.F†ã¾ŒŒ±ù@| VÚ
endstream
endobj
startxref
89569
%%EOF 

A side remark

ID management: Your process adding attachments keeps the whole ID. Your signing process drops the whole original ID of the PDF and replaces it with a new one:

• original.pdf

  /ID[<321A6D6DCD0785E8E35BD4B13115140A><59793561FB914D408936FC170763541A>]
  

• original[with-attachment].pdf

  /ID [<321A6D6DCD0785E8E35BD4B13115140A> <59793561FB914D408936FC170763541A>] 
  

• original[signed].pdf

  /ID [<A9F7159B1E5D8285A68475689B750214> <A9F7159B1E5D8285A68475689B750214>] 
  

• original[with-attachment][signed].pdf

  /ID [<DC60F4419C05967B81D7F64090027D7F> <DC60F4419C05967B81D7F64090027D7F>] 
  

Both approaches are wrong, processes manipulating a PDF and, therefore, creating a new version of it, shall keep the first ID entry and replace only the second one with a unique new one.