Key takeaway
Compressed size is only one input to an ingestion decision. A small package can exceed the recipient’s extraction budget.
Agree on a receiving envelope before extraction
An evaluation package arrives as a compressed archive. Its download size fits the receiving limit, but the expanded contents can consume much more disk, memory and processing time. OWASP’s file-upload guidance says extraction limits need to consider decompressed size. Python’s ZIP documentation also identifies resource exhaustion and incomplete extraction as practical failure modes.
A bounded ingestion plan names the recipient environment, allowed archive types, total expanded-byte budget, per-member budget, file-count cap, nesting depth, processing timeout and path rules. These are constraints chosen for the proposed environment, not universal safety thresholds. A successful download or matching package hash cannot establish that extraction will stay within them.
A package that fits the download cap but fails the envelope
This hypothetical request permits a 200 MB download, at most 1 GB of expanded content, no more than 2,000 files and only the outer archive with one nested archive layer. For this example, MB and GB mean decimal million and billion bytes. The invented manifest describes 120 MB compressed, 1.8 GB expanded and 6,000 members. Its declared expansion ratio is 1,800 / 120 = 15.
The compressed package passes the download check but fails both expanded-size and member-count checks. Those manifest values are declarations, not measured extraction results. If an approved package is later processed, enforce limits against actual bytes emitted and members encountered, with an early stop when a cap is reached. A favorable declared ratio cannot substitute for runtime limits.
| Budget item | Hypothetical limit | Package declaration | Decision |
|---|---|---|---|
| Compressed transfer | 200 MB | 120 MB | Within transfer cap only |
| Expanded total | 1 GB | 1.8 GB | Hold; exceeds receiving envelope |
| Member count | 2,000 | 6,000 | Hold; request a scoped package |
| Nested layers | One below outer archive | Not established | Unresolved; no automatic recursion |
Check paths and collisions independently of size
Validate where each member would be written, including absolute names, parent-directory traversal, links and destination-name collisions. Python’s documentation warns about untrusted extraction and notes that its Path interface does not sanitize member filenames. Do not assume every archive interface supplies the same protections. The ingestion owner must review the actual library and destination behavior.
Use an isolated destination that cannot overwrite the recipient’s existing evaluation outputs. Treat duplicate or platform-normalized filenames as a review issue, not permission to keep the last one silently. Preserve the package inventory, encountered member names and stop reason in a bounded log without exposing record contents. An antivirus result, extension check or CRC test answers a different question from the receiving resource envelope.
Define what happens after a stop
A timeout, byte cap or extraction error should leave an explicit incomplete state. Do not feed partial contents into a benchmark as though the package were complete. Agree on isolation, permitted deletion of temporary extracted files, incident escalation and whether a revised package needs a new approval. Only the responsible recipient should operate that environment; this article does not perform or certify a security inspection.
For the invented package, the useful next step is a metadata-only request for a smaller bounded subset and a complete member inventory. It is not approval to obtain raw seller records or contact a provider. Use the diligence builder to retain the envelope and the readiness planner to assign the missing checks. Named introductions, sample access, extraction permission and a later license remain separate decisions, with no inferred inventory, demand or guaranteed earnings.