[schmitch]

Fixes #815

Problem

Reading the control member of an uploaded or imported .deb (crates/formats/apt/src/deb.rs) bounded the time it took but not the memory. tar reads a GNU long name, long link or PAX header whole before it returns the entry the header describes, up to the 256 MiB the member could inflate to. The xz decoder's window grew alongside. A 39 KB package held over 500 MiB before it was refused, so a few uploads at once could get the pod OOM-killed.

Changes

• Raw tar walk. control_in_tar reads the entries with raw(true), like the npm tarball reader. A long name, long link or PAX header is read only when its header says 64 KiB or less (MAX_EXTENSION_BYTES, the npm reader's cap); a larger one is refused from the header alone. They are applied as tar applied them: at most one of each kind per entry, and the path comes from the long name, then the PAX path, then the header. A PAX size other than the header's and GNU sparse entries are refused, because a raw walk would lay those archives out differently. Control members never contain either.
• Inflate bound 256 MiB → 8 MiB (MAX_CONTROL_TAR_BYTES), counted up to the end of the control file. dpkg-deb sorts the member, so only conffiles and config come before control (checked with dpkg-deb 1.22.6). A builder that puts md5sums first stays under the bound up to about 70,000 files. When the bound is reached, the error names it, and a control file the bound cuts short is refused instead of being read in part.
• Decoder limits.
  • xz: XzReader::new_mem_limit with xz -9's 64 MiB dictionary. dpkg-deb compresses the control member like the data, so -Zxz -z9 declares 64 MiB on it. lzma-rust2 grows its window only as data is decoded, so what it holds follows the 8 MiB bound.
  • zstd: an 8 MiB window, which is what level 19 declares. ruzstd returns nothing from a frame until it has decoded more than a full window, so it holds the whole declared window. With level 22's 128 MiB, a crafted package held 197 MiB here. So the zstd window limit is the memory bound.

Limitation this introduces

dpkg-deb streams control members larger than about 128 KiB. At -Zzstd -z20 to -z22 those declare windows of 32 to 128 MiB, so such packages are now refused with the control member's zstd window is larger than 8 MiB. Levels up to 19 (Ubuntu's zstd packages included) and xz at any level are read. This is documented in docs/apt.md (upload section and Limitations) and in docs/changes/2.2.0/815.limitation.md. apt is new in 2.2.0, so the bug itself never shipped and gets no fixed fragment.

Tests

• Unit tests in deb.rs:

  • every compression, zstd now included;
  • long name, long link and PAX header refused from a header claiming 256 MiB, and read up to the cap;
  • long names and PAX paths naming the next entry, plus the refused layouts;
  • the inflate bound at its edge;
  • xz dictionaries of 8 and 64 MiB read, 96 MiB and 4 GiB refused;
  • zstd windows of 8 MiB read, 16, 32 and 128 MiB refused.

• crates/formats/apt/tests/control_memory.rs: the issue's acceptance test. A counting global allocator, in a test binary of its own, measures what control_file holds on the issue's crafted packages (a 256 MiB GNU long name), built cheaply from concatenated xz streams, a hand-built deflate stream and zstd RLE blocks:

  Package	Held before	Held now
  xz	393 MiB	147 KiB
  gzip	(≈ 256 MiB, per the issue)	78 KiB
  zstd, 8 MiB window	–	12.5 MiB

  The test fails against the old reader.

• Real packages built with dpkg-deb 1.22.6 and an 830 KB md5sums: gzip -z9, xz -z6/-z9, zstd -z3/-z19 are read; zstd -z22 is refused.

• cargo test -p forge-format-apt, cargo clippy -p forge-format-apt --all-targets -D warnings, cargo fmt --check, cargo xtask changelog --check and cargo xtask docs --check pass.

No admin API changes, so no web UI screen applies.

---

Generated by Claude Code