DocuSign generates a pdf with an interesting xref table

[peteris-zealid]

This is more of an open ended question about is it legal to have such a table.

%PDF-1.5
...
...
...
54 0 obj
<</Root 1 0 R/Info 40 0 R/ID[(8d482d3a-23fe-4c06-ab27-e54d418f64c6) (a49896d7-3b3d-4659-954a-bf14fc39ede5)]/Prev 93522/Type/XRef/Index[0 2 31 1 40 15]/W[1 4 4]/Size 55/Filter/FlateDecode/Length 80>>stream
x�c��ÿ@ÀÈÀ�w�Äad`b��1��X�*Âá�,Â�c0Á�,0���Ác°Â�ì@+òu �2��@��
PFÍN(ãß�¨¥�KA��ð
�
endstream
endobj
startxref
133541
%%EOF

The stream decoded looks like this:

0 000000000 FFFFFFFF
0 100016ED4 00000000
0 100020359 00000000
0 200000029 00000000
0 100020842 00000000
0 200000029 00000001
0 200000029 00000002
0 200000029 00000004
0 200000029 00000006
0 200000029 00000003
0 200000029 00000005
0 200000029 00000007
0 100016F2C 00000000
0 100017454 00000000
0 100017920 00000000
0 100017CB9 00000000
0 10001FED0 00000000
0 1000209A5 00000000

On one hand the pdf spec requires the first generation number to be 65535, but on the other hand it would look really awkward to define a 4 byte number and set the "maximum" value as 2**16. pyHanko does validate the particular pdf, but adding a new signature with strict mode is not possible because pyHanko (rightfully) complains about the generation number.

This is a report not a request to change anything in pyHanko.

[MatthiasValvekens]

Heh, that's interesting. Can you share the value of the /Producer entry and/or the XMP document metadata (if any), either in public or in private? That'd help to assess how widespread this issue is, and possibly also to find out who to contact to get it sorted...

Either way, thanks for the heads-up!

[peteris-zealid]

interesting-xref-table.pdf
Here is the pdf.

  <pdf:Producer>PDFKit.NET 22.4.100.37361 DMV9</pdf:Producer>