Security: TAR pre-scan misses GNU long-name and long-link metadata

[rustytrees]

Bug description

preScanTarGz validates PAX path and linkpath overrides, but it does not
apply GNU L (long name) and K (long link) records to the following entry.
Zig 0.16's TAR iterator does apply those records. Malt can therefore validate
the placeholder ustar name or link target while std.tar.pipeToFileSystem
extracts a different effective value.

This is not a claim that std.tar fails to sanitize entry names. Zig calls
sanitizePath on the effective entry name. The mismatch is in Malt's pre-scan.
sanitizePath does not validate symlink targets, and Malt cannot track a
symlink whose GNU long name it never applied.

A malicious bottle can use GNU K to create a symlink with an escaping target
after Malt approved a benign placeholder. It can also use GNU L to hide a
symlink's effective name and then write a later file through that symlink
outside the extraction directory.

Affected code:

• extractTarGz, preScanTarGz, and the GNU metadata branch in src/fs/archive.zig:93-319
• Zig 0.16 std/tar.zig: GNU metadata is applied by the iterator at lines
  430-435, while extraction sanitizes the effective entry name at lines
  601-643.

Regression tests:

• extractTarGz rejects an escaping GNU long-link target
• extractTarGz rejects a write through a GNU long-named symlink
• extractTarGz accepts safe GNU long-name and long-link metadata

Homebrew catalog reference

No official trigger was found in the bounded archive sample. The scan checked
13,457 entries from the fontconfig, libpng, node, openssl@3,
proctools, sqlite, unzip, xz, zstd, minimal-racket, nagios, and
unbound bottles. None used a GNU L or K record. The formula API does not
expose bottle entry types, so this does not rule out other or historical
bottles.

Expected behavior

The pre-scan must consume GNU L and K records with the same one-entry
lifetime and size/NUL rules as Zig's iterator. It must validate the same name
and link target that extraction will use. Malt's existing Rust-bottle-compatible
one-level symlink policy must remain intact.

Fix: #838

[rustytrees]

A harmless runnable PoC is now published:

• h01-gnu-metadata formula
• runner at signed commit bd0e2a4
• v0.1.0 archive and SHA256SUMS

The archive uses GNU L and K metadata. The visible ustar symlink name and target are placeholder and safe; Zig's iterator replaces them with door and an absolute canary directory outside MALT_PREFIX. The later door/escaped entry proves the write through the effective symlink. The archive SHA-256 is 891077343752b5584a3e2854660965fa1bc683428dbb422eddb3c66b88a6f617.

git clone https://github.com/rustytrees/malt-security-pocs.git
cd malt-security-pocs
git checkout bd0e2a4d088cc63c8a7ab1613e851d23808b5a4d
./scripts/run-poc.sh --malt /path/to/malt --expect vulnerable h01

Against exact Malt efd2b993d0ec0e2a7475bdc8986787739b253706, malt install returned 0, installed the package, and created the outside-prefix canary. Against the combined patched build containing #838, extraction was rejected, the package was not installed, the canary remained absent, and the PoC runner returned 0 for the expected patched result.

The fixture only writes under /tmp/malt-security-poc-* and removes its temporary paths on exit. It does not claim that an official Homebrew bottle currently contains this archive shape.