The direct answer
Use an explicit supported extraction filter as a baseline, then apply the narrower member policy your application actually needs. Extract into controlled private staging and release only the complete checked revision. Filter acceptance alone does not establish resource safety, rollback, race resistance, or document trust.
Decide whether the whole bundle may be released
A knowledge-import worker may need two text notes from a tar bundle, without needing Unix ownership, links, executable files, or overwrite semantics. Define that smaller contract before selecting an extraction API. A member passing a library filter and a complete bundle becoming readable by the application are different decisions.
The existing upload preprocessing guide covers quarantine and parser isolation. This guide adds a concrete tar-member policy and an all-or-nothing application release decision. It is a proposed design, not extraction code or a tested sandbox.
Record the effective Python behavior
The tarfile documentation opened for this article identifies Python 3.15.2. Filters were introduced in 3.12; the default became data in 3.14. Backports exist, so verify feature availability and effective configuration on the deployed runtime instead of inferring it from a major-version label. No installed runtime was inspected here.
data rejects specified escaping links and special files, but does not prohibit every link or provide resource-exhaustion protection. Our stricter application profile requires that baseline explicitly, then rejects additional features. Unavailable support means hold, never automatic fallback to fully_trusted.
Specify a notes-only application profile
Invent bundle B-42, owned by synthetic workspace W-A. The consumer needs an optional notes/ directory and regular, non-sparse files directly beneath it. Each filename must be one to forty lowercase ASCII letters, digits, underscores, or hyphens followed by .txt. Directory entries must name exactly notes/. Reject every other original member name or type; do not repair it into an accepted name.
Example ceilings are twenty members including directories, sixty-four KiB per file, and two hundred fifty-six KiB total regular-file bytes. They are invented product requirements, not safe universal limits. Enforce actual processing, memory, disk, and elapsed-time budgets separately. The compressed upload size does not establish expansion cost.
Track every member in archive order, the original name, effective destination identity under the supported filesystem, type, declared size, and admission reason. Reject repeated destinations rather than accepting a later replacement. A filename policy must also account for the actual filesystem's reserved names and equivalence rules; this example is not a portable path validator.
Walk the member and release matrix
| Inert metadata condition | Member decision | Whole-bundle consequence |
|---|---|---|
| notes/ plus regular notes/summary.txt and notes/outline.txt within ceilings | Admit to private staging | Eligible for final inventory and content checks |
| Link to another admitted note, even within staging | Reject symbolic and hard links | No release; confined target is insufficient |
| Original name is absolute, contains a parent component, or uses an unapproved separator | Reject before any name repair | No release; normalization is not admission |
| Second occurrence of notes/summary.txt | Reject repeated destination | No last-member-wins substitution |
| Device, pipe, sparse member, or unexpected directory | Reject outside profile | No release, regardless of suffix |
| Twenty-first member or excessive individual/cumulative bytes | Stop at configured boundary | Mark failed; terminate bounded processing |
| Later member fails after the two notes were written | Abort attempt | Earlier files remain unpublished; cleanup required |
| Destination already contains a file or another writer can modify it | Do not begin this attempt | Require a new controlled workspace |
| Complete staging inventory differs from admitted ledger | Hold for investigation | Never publish the apparently useful subset |
These are metadata cards, not constructed archives. The ordinary two-note row preserves usefulness while making rejected conditions independently reviewable. Admission does not certify the text's meaning or authorize following instructions inside it.
Make rejection fail the bundle, not silently skip a member
PEP 706 explains why the filter runs immediately before each member: earlier members can change the filesystem. A separately reviewed member list is not a precise prediction of later extraction. Its filter contract also distinguishes skipping a member from raising an error.
For B-42, a policy rejection must make the job unsuccessful. Do not implement rejection merely by returning None and then presenting the reduced bundle as complete. Review the effective error policy: the current tarfile documentation describes errorlevel=0 continuing past filter refusals. This profile requires refusals to abort and treats any other processing error as failure.
Record attempt ID, policy revision, runtime/build identity, immutable input reference, admitted inventory, terminal status, and cleanup status. Keep document contents out of routine operational logs. A successful API return is only one input to the application's release gate.
Keep staging, cleanup, and publication separate
Start each attempt in a new private workspace beneath a controlled parent, without pre-existing entries or unrelated writers. Keep the source bytes stable too. A preliminary path check cannot prevent another process from replacing an object between checking and use; the documented live-data limitation remains. Isolation, supported filesystem primitives, and a reviewed publication mechanism must establish the actual boundary.
Partial extraction is not rolled back automatically. On failure, block readers first, stop the worker, and arrange cleanup within the known workspace boundary. If cleanup cannot be confirmed, retain a failed/quarantined state and prevent reuse. Retrying means a fresh attempt and workspace, not continuing over leftover files.
Release only after completion, inventory reconciliation, required content checks, and current authorization. Publish the exact checked objects through a mechanism that prevents concurrent replacement or partial visibility. A rename alone is not a universal cross-filesystem or object-store transaction. Later readers must stay bound to that released revision.
State exactly what remains unverified
Have a second reviewer walk every card against the admission ledger and state machine before authorizing implementation. Actual extractor behavior, filesystem races, resource enforcement, cleanup, and publication atomicity would require separate controlled verification on the selected runtime and platform.
All checks here are PROPOSED_UNRUN. No archive creation, inspection, extraction, file-processor experiment, installation, or model call occurred. Boundary is a prelaunch commercial model router with planned request-path checks; it does not supply a shipped tar extractor, filesystem sandbox, or archive-admission service. The eight mock evaluator tests establish different synthetic behavior.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.