Repository navigation
fix(deps): update module github.com/go-pdfkit/reader to v0.11.0 - #133
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
v0.10.0→v0.11.0Release Notes
go-pdfkit/reader (github.com/go-pdfkit/reader)
v0.11.0Compare Source
CheckLinearized: asking whether a file is what its front saysLinearized(b)has been here since v0.10.0 and answers the cheap question a reader asks before streaming: are the parameters at the front well formed? Of Table F.1's claims it checked exactly one against the file —/Lagainst the byte count — because that is all a reader can afford, having fetched 1024 bytes and resolved nothing.That makes it a weaker test than it looks, and a writer developed against it would pass without linearizing anything:
/O,/E,/Nand/Twere read for type and never consulted, so a file with a correct/Land four invented integers was accepted. That is precisely what a first linearizer emits.CheckLinearized(b)is the other question, for the other caller: not "may a reader trust the front of this file" but "is this file actually what the front says". It opens the document, so it costs what opening costs, and it is the judgement a writer needs on bytes it has just produced. Every parameter must point at what it claims to:/N/O/H/T/E/E, and why a second producer was needed/Eis the parameter a writer is most likely to get wrong, so leaving it ungated was the hole that let a writer be its own judge. It is now checked against the first-page cross-reference section — the one Annex F puts at the front andstartxrefpoints at, whose entries are the first page's objects.The subtlety is that F.3.1 permits the primary hint stream on either side of the first page. qpdf writes it before (
/H550,/E902); Ghostscript-dFastWebViewwrites it after, at/Eexactly (/H829,/E829). A rule that simply took the highest-offset entry would therefore refuse every Ghostscript file. Both qpdf fixtures place it before and cannot tell the two rules apart, which is why a Ghostscript-produced file is committed beside them.Values a 32-bit build cannot address are refused, not truncated
int(Integer)discards the high half whereintis 32 bits, so a/Hlength of 2³²+127 read as 127 — the committed fixture's own hint length, a plausible value every later check then accepted. The same bytes were judged sound on one machine and refused on another, with nothing to say which. Every integer the dictionary offers now goes through one conversion that refuses what it cannot represent,/Pincluded. The new error isErrLinearizationMalformed.Known limits, stated rather than implied
/Eis checked against the first-page cross-reference section, which is not the same as checking the section is right. A writer that omits objects page one genuinely needs produces an internally consistent file that passes. Ghostscript does this on a document with shared fonts, outlines and links:/H=/E= 1941 is accepted here, whileqpdf --checkcomputes5500..5501and reports page one as 9 objects where the hint table claims 4. Deciding what page one needs means walking its resources — the partition the hint tables describe — and that judgement is still outstanding./H's extent is checked./Pis range-checked but nothing cross-checks its value.One deliberate disagreement with qpdf
qpdf computes
/Eas a range (901..902on the committed fixture), accepting the end with or without the line ending afterendobj. This requires the end including it, which is what both measured producers write. A file carrying the lower value would passqpdf --checkand be refused here; none has been observed, and the alternative is a window that cannot tell a correct/Efrom one a byte short — the same argument that made the/Hlength an exact comparison.Across the rest, there are 0 disagreements with qpdf over 42 generated files: 1, 2, 3, 5, 25 and 100 pages × plain, object streams, uncompressed streams, 256-bit encryption and
--newline-before-endstream.All limits are tracked in #40.
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Mend Renovate CLI.