Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using TSA causes a extra xref size #77

Open
Jacq opened this issue Jul 23, 2024 · 4 comments
Open

Using TSA causes a extra xref size #77

Jacq opened this issue Jul 23, 2024 · 4 comments

Comments

@Jacq
Copy link

Jacq commented Jul 23, 2024

I am testing the TSA feature (set_tsa and not set_ltv) with a dompdf generated pdf, after the signing I load again the PDF with "$pdfDoc = PDFDoc::from_string($pdfSigned);" doing this several times with the same input sometimes $pdfDoc returns true;

The error is related to "xref tag not found at position", I checked the signed pdf buffer and in some cases the xref_pos size is different, when using TSA feature sometimes it adds 4 chars to the xref_pos, this is an example of PDF signed with TSA and checked correctly with startxref 17394:

endobj
xref
0 2
0000000000 65535 f 
0000001723 00000 n 
5 2
0000001335 00000 n 
0000001613 00000 n 
10 3
0000001476 00000 n 
0000001501 00000 n 
0000001822 00000 n 
trailer
<</Size 13/Root 1 0 R/Info 5 0 R/ID[<1a3d216a394bb6ba74fb5cc1fd4391fe> <1a3d216a394bb6ba74fb5cc1fd4391fe>]/Prev 984>>
startxref
17394
%%EOF
'

and this is the same PDF signed again that reports startxref 17398 bytes:

endobj
xref
0 2
0000000000 65535 f 
0000001723 00000 n 
5 2
0000001335 00000 n 
0000001613 00000 n 
10 3
0000001476 00000 n 
0000001501 00000 n 
0000001822 00000 n 
trailer
<</Size 13/Root 1 0 R/Info 5 0 R/ID[<454c825cf55cc68453eea7ab2eb1315b> <454c825cf55cc68453eea7ab2eb1315b>]/Prev 984>>
startxref
17398
%%EOF
'

In the second case the function "public static function get_xref_1_4" xref_line starts in "obj\n" instead of "xref\n" and the code reports the "xref tag not found at position".

I could fix the code to detect this 4 bytes shift when searching the xref anchor but the bug itself is probably upstream when applying the TSA signature, as the documents have the same exact sizes with different signatures, any ideas?.

I have repeat the test several times without set_tsa, or with set_ltv and it only triggers with set_tsa, I am testing with the digicert timestap service.
Cheers
Jacq

@dealfonso
Copy link
Owner

Hi,

I also had some glitches when testing TSA, but I thought it was my fault... let's debug

@parallels999
Copy link
Contributor

parallels999 commented Jul 23, 2024

CC: @hidasw, related #70

  • There was another PR for TSA, maybe you could compare it to see where the problem is, Support timestamp #52

Maybe it's not because __SIGNATURE MAX_LENGTH is now variable, and performs a pre-signature to calculate the size

@hidasw
Copy link
Contributor

hidasw commented Jul 23, 2024

CC: @hidasw, related #70

  • There was another PR for TSA, maybe you could compare it to see where the problem is, Support timestamp #52

Maybe it's not because __SIGNATURE MAX_LENGTH is now variable, and performs a pre-signature to calculate the size

I'm currently away from computer and not possible to analyze it soon.
but you can try to pre defined __SIGNATURE MAX_LENGTH to 20000 or above.
I suggest to set at about 32000.
let me know what happen.

@Jacq
Copy link
Author

Jacq commented Jul 29, 2024

It was already at 27742, increasing it to 32000 does not look to mitigate the issue, it still fails every one or two successes.
Cheers
Jacq

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants