Skip to content

BUGFIX: Cap total uncompressed size in data-tar validation - #42

Draft
bmdavis419 wants to merge 1 commit into
mainfrom
muse/tx9-audit-fix
Draft

bmdavis419 wants to merge 1 commit into
mainfrom
muse/tx9-audit-fix

Conversation

@bmdavis419

@bmdavis419 bmdavis419 commented Oct 13, 2026 •

Copy link
Copy Markdown
Contributor

Caps total uncompressed archive size in ValidateDataTar, so a crafted .tx9 can no longer pass validation and then expand without bound onto a box volume during tx9 import.

  • The validator already capped member count (1M) but summed nothing: a tiny gzip could declare multi-hundred-GiB regular files and only fail when the target disk filled mid-restore.
  • The fix rejects archives whose regular-file members sum past 100 GiB, and rejects negative member sizes instead of letting them offset the total.

Why this item (highest-value open reliability/correctness fix):

Considered from docs/audit-2026-08-27.md + docs/audit-2026-10-04.md:

  • Executor admin-token / restricted agent identity, published-endpoint defaults + token rotation, reproducible pinned images, per-box disk/history retention quotas, Executor backup portability — all real, but all are product/policy decisions only Ben can make (the Aug 27 "Decisions left open" table); this PR deliberately does not pick defaults for them. The 100 GiB ceiling here is not that quota decision: it mirrors the decompression-bomb safety limit guest/hermes-state already ships (MAX_UNCOMPRESSED), so it needs no new product call.
  • Log SQLite snapshot consistency (no live read transaction) — real correctness gap, but a proper fix must not reopen DB paths through mutable directories (the exact bug the private-snapshot design fixed); larger, riskier change, and current code warns rather than silently misreading. Left open, noted in the audit doc.
  • Log redaction completeness — best-effort by design; cannot be made complete.
  • Large log/snapshot exhaustion — overlaps the open retention-budget decision above.
  • Hermes live-updater PM migration / ARM64 proving — needs upstream + live infra, not a hermetic code fix.
  • CI + README install docs — already covered by CHORE: Add GitHub Actions CI and install/contributing docs #40/CHORE: Add GitHub Actions CI and install docs #41; not duplicated.

This item wins because any .tx9 file a user is handed can trigger it today, validation already runs before extraction (so the gate is cheap and fail-fast), and it is testable hermetically with no Docker.

Important files:

internal/archive/validator.go

  • Adds maxArchiveUncompressedBytes (100 GiB, test-lowerable var like maxArchiveMembers) and enforces the cumulative regular-file total during header collection, before any extraction writes.

internal/archive/validator_test.go

  • Adds cumulative-over-cap rejection (payload split across two files, so a per-member check cannot pass it) and an exactly-at-cap acceptance test. Both failed before the fix (undefined: maxArchiveUncompressedBytes / no cap) and pass after.

docs/audit-2026-08-27.md

  • Marks the archive-size item addressed, scoped explicitly so the open quota/retention decision and the log-snapshot items remain open.

Checks: make check passed (syntax, ShellCheck, guest regressions, gofmt, go vet, go test ./...); focused go test ./internal/archive/ -run TestValidateDataTar passed. Draft only — not merged, nothing deployed or released.

Note

Cap total uncompressed regular-file size at 100 GiB in ValidateDataTar

archive.ValidateDataTar now sums the declared sizes of regular-file members while scanning tar headers and rejects the archive if the total exceeds a new 100 GiB limit. It also rejects regular members with a negative size. Both checks run before any extraction logic. An archive whose total exactly equals the limit is still accepted. The limit lives in the mutable package variable archive.maxArchiveUncompressedBytes so tests can adjust it; new tests in validator_test.go cover the exceeded and exact-boundary cases.

  • Behavioral Change: archives with cumulative regular-file payloads over 100 GiB, or containing a regular member with a negative size, now fail validation in validator.go.

Macroscope summarized 35f5790.

ValidateDataTar capped member count but not summed regular-file size,
so a small crafted .tx9 could pass validation and expand without
bound when tx9 import extracted it onto a volume. Reject archives
past 100 GiB total (mirroring guest/hermes-state MAX_UNCOMPRESSED)
and reject negative member sizes. Includes cumulative and boundary
regression tests and marks the 2026-08-27 audit item addressed.
@coderabbitai

coderabbitai Bot commented Oct 13, 2026

Copy link
Copy Markdown

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

  • Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant