release: preflight wheel member count before ZipInfo materialization

[seonghobae]

Buyer-visible release-verification resource gap

Fresh protected main 7faf7a3b8a47980113982914000e724ab6a6cda5 still opens the final publication wheel with zipfile.ZipFile(...) before applying any semantic member-count ceiling in scripts/ci/verify_distribution.py. ZipFile parses and materializes the complete central directory into ZipInfo objects during initialization, after which _verify_wheel(...) calls namelist() and builds another complete Python list before path validation.

This is distinct from #69's already-integrated bounded SBOM generator and is the wheel-side sibling of #215/#216. The SBOM generator already preflights the ZIP end record and central directory before allowing ZipFile to allocate member objects; the final publication distribution verifier remains a separate evidence authority and does not yet do so.

RCA

First failing boundary: final wheel publication verification, after a bounded immutable source snapshot is created but before ZipFile central-directory object materialization.

Immediate cause: _verify_wheel(...) constructs zipfile.ZipFile(wheel_file) with no prior finite central-directory member-count admission. namelist() then creates a second full list.

Systemic cause: the verifier has a compressed 256 MiB file ceiling and stable snapshot/digest binding, but no independent finite semantic wheel-member ceiling before the standard-library ZIP parser allocates one ZipInfo per central-directory entry.

Falsifiable hypothesis: if the stable snapshot receives a bounded canonical EOCD/central-directory preflight that rejects an over-budget or unsupported ZIP structure before ZipFile(...), then later standard-library semantic parsing is bounded by the reviewed member ceiling and cannot allocate an unbounded number of ZipInfo objects.

Distinct remedies / feasibility

1. Preferred: reuse the already-proven EgressWeave SBOM design at this separate parser boundary: bounded EOCD tail read, single-disk/non-ZIP64 canonical central-directory validation, count entries before ZipFile, reject above an explicit finite member ceiling, reset the snapshot, then run normal ZipFile semantic verification.
2. Open ZipFile and check len(infolist()) or len(namelist()) afterward: rejected because the complete ZipInfo set has already been materialized.
3. Rely only on the 256 MiB compressed-file ceiling: rejected because metadata object count and Python object overhead are not independently bounded by compressed bytes.
4. Delegate final verification to the SBOM generator: rejected because publication verification and SBOM generation are distinct evidence authorities with different outputs and failure contracts.

Acceptance criteria

• Add immutable test-only RED evidence on the exact current release: bound sdist and wheel verifier member enumeration #216 accepted-tree candidate proving an over-budget canonical wheel reaches the current verifier without a semantic wheel-member rejection.
• Add a deterministic finite MAX_WHEEL_MEMBERS contract and reject over-budget central-directory entry count before zipfile.ZipFile(...) is constructed.
• Validate one canonical single-disk, non-ZIP64 central-directory framing path with bounded reads; fail closed on inconsistent EOCD/count/size/offset or ZIP64/multi-disk forms outside the canonical release contract.
• Preserve unsafe/duplicate path rejection, required package/schema/license/metadata checks, exact version/Requires-Python/license metadata, stable source snapshot/digest binding and checksum publication bytes.
• Do not extract wheel contents or add a dependency/credential/network/repository authority.
• Preserve Python 3.10–3.14, Ruff, compileall, wheel/sdist/installed-package acceptance and exact 100% owned-production statement/branch coverage.
• Pass exact-head CI/SAST and all live required workflow evidence. Wrapper-green with the actual pinned Dependency Review step skipped is non-passing; pending/unavailable/no-report Strix is likewise non-passing.
• Keep this implementation on the existing release: bound sdist and wheel verifier member enumeration #216 verify_distribution.py writer lane; do not create a competing branch for the same path.
• Merge only an unchanged gate-clean exact head and verify the bounded final wheel/sdist verifier from protected main.

Non-goals

• No general-purpose arbitrary ZIP interchange support.
• No weakening of security: bound archive member enumeration before materialization #69's stricter SBOM archive parser.
• No EgressWeave-local substitute for organization-owned Dependency Review, Strix or reviewer controls.

[seonghobae]

Current implementation evidence is concentrated in the required existing lane, Draft PR #216 (release: bound sdist and wheel verifier member enumeration).

Fresh identities at this update:

• protected main: 7faf7a3b8a47980113982914000e724ab6a6cda5;
• release: bound sdist and wheel verifier member enumeration #216 exact head: a6f1bea8b410a19fc3a9f87e0244c6b7826de6c1;
• wheel RED commit: 89d99625b79e8a32833250ec9e2271d5ef9ec45a;
• wheel production fix: a6f1bea8b410a19fc3a9f87e0244c6b7826de6c1.

The current implementation preflights the canonical EOCD/central-directory shape before zipfile.ZipFile(...), rejects unsupported ZIP64/multi-disk structure on this release boundary, enforces the finite distribution-member ceiling before ZipInfo materialization, preserves existing package/path/content checks, and cross-checks the later ZipFile member count against the preflight count. The regression also asserts that preflight occurs before ZipFile construction and that an over-budget canonical wheel is rejected.

Exact-head repository CI, SAST, CodeQL/code-quality, Python 3.10–3.14 and package verification are successful on a6f1bea8.... The wheel test-only hosted run was cancelled/superseded, so that cancelled result is not treated as passing RED evidence; immutable test-before-fix commit ordering remains lineage evidence.

Two required security boundaries are not passing despite green wrapper/check conclusions:

• Security Scan run 31655933790, dependency-review job 94310258704: the actual immutable-pinned Dependency review step is skipped after the support probe.
• Strix required workflow job 94310300291: the exact-head annotation states Strix backend unavailable and explicitly says no vulnerability report was produced. Under the repository's fail-closed evidence contract this is unavailable semantic evidence, not a substantive security pass.

The OpenCode/Noema wrapper conclusions likewise are not substituted for a qualifying semantic verdict when their underlying authenticated review chain has not produced one. No formal PR reviews or inline review threads are present on the current exact head.

#216 therefore remains Draft and this issue remains open. The Dependency Review availability problem is tracked in #76; the Strix fail-closed control-plane gap is tracked in #197 / organization issue ContextualWisdomLab/.github#891. Both organization-owned repairs are read-only from this writer. No clean-head churn or EgressWeave-local substitute is justified. Close #217 only after unchanged accepted #216 reaches protected main and the bounded wheel verifier is revalidated there.