Archive Member Path Review: Inspect ZIP and Tar Entries Before Extraction

The source dates shown in this guide identify documentation checks on 22 October 2026, not original publication dates. Follow each citation for the archive behavior being discussed. Begin with a controlled archive reference, digest, format, producer if known, and an intended destination root such as SYNTHETIC_ROOT. The destination is a review input, not a promise that extraction is allowed.

The Python Software Foundation, 22 Oct 2026 (opens in a new tab) documentation says callers should inspect member names before extracting and should not extract an untrusted archive without prior inspection. It describes absolute names and names containing .. as cases an extraction tool may sanitize or reject, while noting that the caller still owns validation. Treat the archive library as an observation source, not as a replacement for your policy.

Keep the raw name for evidence and a separately derived candidate for review. Never overwrite the source field with a cleaned spelling. A report that only says “safe path” loses the fact that an archive supplied an absolute name, a parent segment, or a link target.

Review absolute paths, drive-letter forms, UNC-like prefixes, repeated separators, dot segments, parent segments, empty names, and names that become equal after normalization. Check both slash conventions when the archive may have been produced on another platform. A name that looks relative in the archive can still resolve outside the intended root after a join and normalization operation.

1. 01Preserve the raw member name and a stable member index.
2. 02Normalize separators and dot segments for the receiving platform without changing the evidence field.
3. 03Resolve the candidate against the declared destination root and compare the result with that root using the receiving platform rules.
4. 04Check case-folding and Unicode normalization collisions when the destination filesystem may treat names as equivalent.
5. 05Record a separate finding for duplicate normalized destinations, even when raw names differ.

Synthetic member manifest

archive_member | raw_name                  | type    | normalized_candidate       | disposition
000             | reports/summary.txt        | file    | SYNTHETIC_ROOT/reports/summary.txt | allow
001             | ../outside.txt             | file    | outside destination        | reject
002             | /absolute/start.txt       | file    | absolute destination       | hold
003             | reports/./summary.txt     | file    | SYNTHETIC_ROOT/reports/summary.txt | duplicate
004             | links/latest              | symlink | SYNTHETIC_ROOT/links/latest | inspect target first

The rows are invented and show the shape of a report, not the output of an extractor. A duplicate normalized destination is its own ambiguity: two members could compete for one output path or change the meaning of an earlier member. Do not silently select the last entry.

Path text is not the whole member contract. Tar archives can represent symbolic links, hard links, device nodes, and other special types. ZIP metadata can also expose type information depending on the producer and reader. The Python Software Foundation, 22 Oct 2026 (opens in a new tab) documentation describes extraction filters that reject absolute paths, paths outside the destination, links that resolve outside it, and special files under its data-oriented filter. Record what the reader reports and do not infer that every archive library or every filter has the same policy.

A link target must be inspected independently of the link name. Check whether the target is relative to the member directory, whether normalization changes it, whether the target member exists, and whether the resolved destination remains under the declared root. If any part is unavailable, retain an unavailable state instead of treating it as a safe regular file.

Run the review against synthetic names before opening a private archive. The fixture should contain a safe relative file, a parent segment, an absolute-looking name, a normalized collision, a symlink, a missing link target, and a special type if the test reader can represent it. Keep private paths, usernames, source labels, and raw content out of the worksheet.

Separate archive evidence from decisions about source authority, privacy, rights, retention, and downstream use. A path review can identify a traversal-shaped name or an unexpected link, but it cannot establish who supplied the archive, whether the files may be retained, or whether the extracted content is accurate. Keep those questions in the owner-approved provenance and handling record.

Pair this guide with the data provenance log for source and custody notes and export guidance for tool-specific behavior. After the owner has a supported non-health scope, authority to describe the collection, and a controlled metadata or synthetic packet, the qualified appraisal request path may be a next preparation step. It does not extract archives, approve paths, create a quote, match a buyer, issue a legal opinion, or grant a license.

Takeaways

• Inspect every member before deciding whether extraction is allowed.
• Keep raw names, normalized candidates, link targets, and dispositions in separate fields.
• Treat parent segments, absolute-looking names, collisions, links, and special types as explicit findings.
• Use synthetic fixtures and bounded metadata before exposing private archive content.
• Keep path evidence separate from provenance, privacy, rights, retention, and accuracy decisions.