security: bound direct SBOM archive input before parser execution

[seonghobae]

Buyer-visible resource-bound gap

The shipped repository-local scripts/ci/generate_release_sbom.py entry point accepts an arbitrary wheel or gzip source distribution and enters zipfile.ZipFile(...) / tarfile.open(...) before enforcing a finite bound on the compressed archive itself. It limits archive-member count and metadata bytes, but the direct CLI/API path can still spend unbounded parser CPU, memory, and I/O on an oversized archive before those later checks run.

PR #64 adds an early archive-size preflight to the higher-level six-file preparer. That is valuable defense in depth, but it does not repair direct callers of build_sbom(...), the attestable adapter, or the standalone CLI. The generator should own the finite-input contract at its parser boundary.

Acceptance criteria

• Add an immutable test-only RED commit proving an exact-name oversized sparse wheel and source distribution are rejected before zipfile.ZipFile or tarfile.open is invoked.
• Define one finite compressed-artifact bound aligned with the sealed-evidence verifier's 256 MiB release-artifact limit without importing the package under test.
• Require the current path to be a regular non-symlink file and enforce its compressed-byte bound before any archive parser or metadata reader executes.
• Normalize filesystem failures and unsafe/non-regular inputs to stable non-leaking errors.
• Retain archive-member, path, link/device, metadata-byte, dependency-lock, exact-artifact digest, and deterministic-output checks as independent defenses.
• Preserve standalone operation and the attestable adapter contract; add no network, dependency, credential, workflow, release, tag, ref, signing, attestation, or publication behavior.
• Add beginner-readable operator guidance and an [Unreleased] Security entry; do not bump the version.
• Pass Python 3.10–3.13, the complete suite, Ruff, compileall, public-docstring checks, 100% production statement and branch coverage, package acceptance, SAST, Security Scan, completed exact-head automated review, independent non-author approval, and repository protections.

Standards basis

MITRE CWE-400 describes uncontrolled resource consumption and recommends limiting resources an untrusted actor can cause a system to expend. Python's zipfile documentation explicitly warns that decompression bombs can exhaust system resources. This repair is a finite-input precondition, not a claim that archive parsers are free of all decompression or mutable-storage risks.

Primary references (APA 7th)

MITRE Corporation. (2026). CWE-400: Uncontrolled resource consumption (CWE Version 4.20). https://cwe.mitre.org/data/definitions/400.html

Python Software Foundation. (2026). zipfile — Work with ZIP archives (Python 3.13.14 documentation). https://docs.python.org/3.13/library/zipfile.html#decompression-pitfalls

Non-goals

• No release-workflow integration or publication.
• No archive extraction.
• No SLSA Build level or provenance claim.
• No change to network transport or egress policy.