[tannevaled]

Closes #43.

#43 reported this and declined to fix it, on the grounds that DrawPNG is a
writer's API and deciding who pdfkit's callers are belongs to the
maintainers. Here is that decision, and the reasoning, because the answer is
not "add a limit to everything".

The number the defect is made of

IHDR's width and height are four-byte unsigned integers over 0..2³¹-1 (W3C
PNG 3rd ed. §11.2.1) and nothing in the file has to back them up.
png.Decode allocates from them before it reads a sample.

Measured here, against this branch with the check cut back out:

the fixture	75 bytes — a real one-pixel PNG whose IHDR says 20000×20000, CRC recomputed so every decoder accepts it
without the check	1526.0 MiB held, then "decode png: not enough pixel data"
with it	0.0 MiB, "a PNG of 20000x20000 is 400000000 pixels, past the 40000000 allowed"

1526.0 MiB is the same figure go-gfx/gfx#72 measured for the same bomb, and
go-pdfkit/convert#4 measured 381.6 MiB for a 10000×10000 claim.

The check reads IHDR with png.DecodeConfig and refuses before decoding.
⛔ A ceiling applied to what a decoder returns is not a ceiling, it is a
post-mortem — and the spec asks for the same reading order: "PNG decoders
should detect errors as early as possible" (§4.10). The product is taken in
int64 because both factors are the file's.

Options.MaxPixels defaults to DefaultMaxPixels = 40 << 20 = 41 943 040
— exactly 160 MiB at the four bytes a pixel image/png returns, a little over
A4 at 600 dpi.

⛔⛔ This started out as 40 000 000, with "the same ceiling
go-pdfkit/render uses" in the doc comment, the README and this body — and I
had not opened render.go. It says const defaultMaxPixels = 40 << 20
(render.go:79): 41 943 040. I had copied the figure, and the claim, from
go-gfx/gfx's svg package, which asserts the same parity in two places
(svg/svg.go:79, README.md:46) and carries the same constant again in
codec/codec.go:201. Three repositories asserting an equality none of them
had opened the file to confirm, and this PR was about to be the fourth.
Filed as go-gfx/gfx#92; corrected
here by reading render.go and saying so in the comment. Neither number was
more correct — what was wrong was a statement of fact with no witness behind
it, which is the kind of thing that travels.

⛔ What is deliberately left unbounded

Stating this because "it has a limit" otherwise reads as "everything has one",
and a limit added where it saves nothing only refuses real documents.

• DrawJPEG decodes nothing. The bytes become a DCTDecode stream and the
  geometry comes from SOF, so a hundred-megapixel scan costs pdfkit its own
  length. Nor are its dimensions a lie the consumer discovers later: the
  consumer decodes the same JPEG.
• DrawImage is handed pixels the caller already holds. Refusing them
  saves nothing; it copies them once more, a constant factor rather than an
  amplification. samples()'s w*h*3 would overflow int on a 32-bit build
  only past 715 megapixels — 2.8 GB of pixel buffer the caller could not have
  addressed to get here.

⛔ And one check that is deliberately not copied

go-pdfkit/convert#4 measures the size again after decoding, because in
general a header is a claim. Not repeated: png.DecodeConfig and png.Decode
read their dimensions from the same IHDR, so a second comparison could not
differ, and an unreachable branch is a comfort rather than a check.

That is an assumption about image/png, not a theorem — so
TestTheDecodedSizeIsTheSizeTheHeaderDeclared holds it up. If a Go release
ever makes the two disagree it goes red, instead of the gap being found through
a 1.5 GiB allocation.

⛔⛔ The bomb test carries its own control

A child process caps its own address space at 1 GiB (RLIMIT_AS, set in
the child because os/exec has no rlimit of its own) and must refuse the bomb
and exit cleanly. The bomb never touches the host's memory, which matters on a
machine running two dozen sessions.

A clean exit proves nothing by itself, so a second child decodes the same
bytes with no ceiling under the same limit and must die. If it ever survives,
the limit is not being applied and the first child's exit meant nothing.

macOS rejects RLIMIT_AS outright (EINVAL), so there both children skip —
loudly, naming the platform, leaving the heap measurement to carry the proof.

Controls

Run against this branch with the two guard statements removed — a behavioural
cut, not a syntactic one, so nothing failed for being unbuildable:

TestAPNGIsRefusedFromItsHeaderBeforeItsPixelsAreAllocated
  "refused as \"decode png: not enough pixel data\", which is not a refusal about its size"
  "refusing it held 1526.0 MiB: the ceiling is being applied after the allocation it is meant to bound"
TestTheCeilingCanBeRaisedAndLowered
  "a million pixels passed a ceiling of 999999"
TestAnOrdinaryPictureIsStillEmbedded            PASS

The last one is the point: a ceiling tested only from above is satisfied by
refusing everything.

No timings are quoted — this machine was at a 1-minute load of 19.2. Held-heap
figures are per-process and unaffected.

🤖 Generated with Claude Code