Re-pin the seed: pkgconf 2.4.3 with the underflow fix, GNU patch, applet trim

P1.4 of the packaging-v2 plan. core-buildenv moves 894ca74b... -> 5a5f8b0d06f267cec431cadf57992ab056687bb21e7e8f7f6a68ee88ec4107e9, which invalidates every identity in the channel. That is the point: it is a flag-day, and P1.5 executes it.

pkgconf: t-79ca IS NOT A VERSION PROBLEM ---------------------------------------- The abort is latent undefined behaviour in pkgconf's own source that only zig's runtime safety traps. libpkgconf/parser.c does

  p = value + (strlen(value) - 1);

which, for an empty dependency-list field, computes value + SIZE_MAX -- a pointer before the start of the object. Byte-identical line in 1.9.5 (:88) and 2.4.3 (:95). There is no release that fixes it.

Measured, all four: 1.9.5 zig EXIT 134 + Zig panic 2.4.3 zig, unpatched EXIT 134 + the identical panic 2.4.3 host gcc EXIT 0, correct cflags (mechanism control) 2.4.3 zig + this fix EXIT 0, correct cflags

Verified in both directions as the plan's section 8 item 7 requires: all five empty dependency-list fields and the Requires-chain case accepted, AND a genuinely absent package still reported absent while a present one is reported present. A pkgconf that accepts everything is not a fix.

DO NOT "FIX" THIS BY ADDING -O2. zig cc -O2 selects ReleaseFast, which turns the safety check off. Measured: the symptom vanishes and the pointer underflow stays. This script builds without -O2 on purpose.

Audit bound with its limit: 27 .c/.h files under libpkgconf/ and cli/ scanned; 2 matched the ptr + strlen(x) - 1 shape; 1 unguarded (this one), the other guarded by an empty-string check. That covers only that syntactic shape. Other pointer underflows in pkgconf are not ruled out.

GNU patch (section 8 Q4, decided by David 2026-07-31) ----------------------------------------------------- Measured with the builder's own patch -p1 -N -i invocation, against the seed-built binary:

  garbage / no-hunk    busybox EXIT 0 silent  |  GNU EXIT 2 "Only garbage..."
  wrong context        both EXIT 1
  applies cleanly      both EXIT 0, file changed   (positive control)
  already applied      both EXIT 1

Row 1 is the whole reason. The recorded sha256 on a patch input moves from being the SOLE guard against a corrupted patch to being defence-in-depth.

Row 4 falsifies section 8 Q4's supporting argument 2, which claimed GNU's --forward exits cleanly on a re-apply. It does not; both exit 1. The decision survives on row 1, which was always the load-bearing argument. Recording that it outlived one of its supports.

Applet trim ----------- 404 applets -> 397. Exactly 404 - 7 (wget nc telnetd httpd sendmail ftpd tftp), with patch accounted for separately: the busybox symlink is skipped so GNU patch owns the name. No unexplained delta.

With the P1.1 network namespace in place this is defence-in-depth, not the thing keeping the network out. Saying so rather than overselling it.

Refusals, and why they are written the way they are --------------------------------------------------- Every sed here is followed by a grep verification, because sed -i exits 0 when it matches nothing. Every applet check runs in BOTH directions, because a trim that trims nothing and a trim that trims everything both pass a one-directional check. The sandbox-tool check exists so that a seed which lost unshare cannot look to the builder like a host that forbids user namespaces.

Sabotage-tested individually, with a positive control: healthy seed EXIT 0 (stands down) trimmed applet survives EXIT 1 required tool missing EXIT 1 sandbox tool missing EXIT 1 pkgconf missing EXIT 1 pkgconf sed matches nothing EXIT 1 "did not apply" two occurrences on one line EXIT 1 "still present"

That last red is why the sed carries s///g. With g, the second grep no longer has a trigger I can construct, so the script labels it as a belt against a future edit rather than a check with a demonstrated red.

Determinism ----------- Three independent builds, two of them at different path depths, all produce 5a5f8b0d... Both hashes asserted non-empty before comparison, because awk on an empty file exits 0 and would MATCH nothing (t-f2c4).

NOT DONE, and it is a release action: MANIFEST now points at a seed-v2 release URL that does not exist yet. The tarball must be published there before P1.5, or a fresh clone's bootstrap fetches the old artifact and refuses on hash mismatch.