[PR #2314] [CLOSED] test(artifacts): exercise ASAR header admission boundaries #5159

Closed
opened 2026-10-31 01:04:25 +00:00 by bsakaguchi · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/2314
Author: @jcamargos
Created: 10/12/2026
Status: ❌ Closed

Base: main ← Head: codex/asar-header-adversarial


📝 Commits (2)

  • 4db3640 test(artifacts): exercise ASAR header admission boundaries
  • 7c50694 test(artifacts): pin the documented ASAR header budget

📊 Changes

1 file changed (+115 additions, -0 deletions)

View changed files

➕ tests/boundary/filesystem/asarHeaderAdmission.test.ts (+115 -0)

📄 Description

Summary

Add a deterministic adversarial regression corpus for ASAR header admission. The reader already checks header extents and a 16 MiB decode budget before handing bytes to the upstream decoder; these tests protect the boundary directly with real filesystem reads. No new production bug or vulnerability is claimed.

Problem and expected behavior

Existing ASAR suites cover streaming, snapshots and cleanup, including one malformed-header/failed-close case. They do not systematically exercise every truncation of a serializer-produced header or the exact decode-budget boundary. A weakened admission check could allow the upstream decoder to allocate from forged header sizes.

Change and scope

  • Positive control generated with the installed @electron/asar serializer; source bytes remain unchanged by admission.
  • Reject every truncated prefix before the end of that serialized header; an intact header remains admissible independently of member data.
  • Exercise 18 contradictory/unsigned-boundary size-field mutations.
  • Check exact 16 MiB admission versus 16 MiB + 4 rejection using file extents without allocating header-sized JavaScript buffers. These fixtures test extent admission, not JSON decoding.
  • Verify admission performs exactly one 16-byte read at offset zero for each case and close every descriptor; temporary directories use the shared fixture cleanup.

Contract and boundary impact

  • Semantic owner: tests/boundary/filesystem/asarHeaderAdmission.test.ts.
  • Ordinary regression coverage within existing scope; no new authority or maintainer scope decision needed.
  • CLI/MCP, provider, Evidence, package metadata and production behavior: unchanged.
  • Effects: test-owned temporary files and read-only admission calls; no external target/provider.

Evidence and regression coverage

Deliberately weakened the production header limit by four bytes during a local mutation probe: the exact-boundary test failed because admission resolved instead of rejecting. Restored AsarHeader.ts byte-for-byte in a finally block and confirmed no production diff; all four tests then passed. The mutant is not part of this PR.

Validation performed

Windows x64, Node 24.18.0 / npm 11.16.0, base bb26622670:

  • npm run test:focused -- tests/boundary/filesystem/asarHeaderAdmission.test.ts: passed, 4 tests including compiled prerequisites.
  • Restored-source Vitest run: 4 passed after the deliberate failing mutation.
  • npm run check: passed, lint 0 errors / 932 repository warnings.
  • npm run verify:test-discovery: 963 files discovered exactly once.
  • git diff --check: passed.

Compatibility, safety, and release

Tests only; no dependencies, release metadata, migrations or runtime changes. This is a bounded deterministic corpus, not a general fuzzing service, full archive-parser proof or end-to-end performance benchmark. No native Windows-control or real-provider coverage is claimed.

Before merge

  • Coverage protects a concrete allocation/admission boundary.
  • Real serializer and filesystem positive controls accompany negative cases.
  • Mutation probe demonstrated a meaningful failing regression.
  • No unrelated changes, generated artifacts or external samples included.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/2314 **Author:** [@jcamargos](https://github.com/jcamargos) **Created:** 10/12/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `codex/asar-header-adversarial` --- ### 📝 Commits (2) - [`4db3640`](https://github.com/morluto/rea/commit/4db3640701032347ec6f33fcb1b8071d1f45aee1) test(artifacts): exercise ASAR header admission boundaries - [`7c50694`](https://github.com/morluto/rea/commit/7c506946f5c7e99948e9dd3fe20738830ecdcb44) test(artifacts): pin the documented ASAR header budget ### 📊 Changes **1 file changed** (+115 additions, -0 deletions) <details> <summary>View changed files</summary> ➕ `tests/boundary/filesystem/asarHeaderAdmission.test.ts` (+115 -0) </details> ### 📄 Description ## Summary Add a deterministic adversarial regression corpus for ASAR header admission. The reader already checks header extents and a 16 MiB decode budget before handing bytes to the upstream decoder; these tests protect the boundary directly with real filesystem reads. No new production bug or vulnerability is claimed. ## Problem and expected behavior Existing ASAR suites cover streaming, snapshots and cleanup, including one malformed-header/failed-close case. They do not systematically exercise every truncation of a serializer-produced header or the exact decode-budget boundary. A weakened admission check could allow the upstream decoder to allocate from forged header sizes. ## Change and scope - Positive control generated with the installed @electron/asar serializer; source bytes remain unchanged by admission. - Reject every truncated prefix before the end of that serialized header; an intact header remains admissible independently of member data. - Exercise 18 contradictory/unsigned-boundary size-field mutations. - Check exact 16 MiB admission versus 16 MiB + 4 rejection using file extents without allocating header-sized JavaScript buffers. These fixtures test extent admission, not JSON decoding. - Verify admission performs exactly one 16-byte read at offset zero for each case and close every descriptor; temporary directories use the shared fixture cleanup. ## Contract and boundary impact - Semantic owner: tests/boundary/filesystem/asarHeaderAdmission.test.ts. - Ordinary regression coverage within existing scope; no new authority or maintainer scope decision needed. - CLI/MCP, provider, Evidence, package metadata and production behavior: unchanged. - Effects: test-owned temporary files and read-only admission calls; no external target/provider. ## Evidence and regression coverage Deliberately weakened the production header limit by four bytes during a local mutation probe: the exact-boundary test failed because admission resolved instead of rejecting. Restored AsarHeader.ts byte-for-byte in a finally block and confirmed no production diff; all four tests then passed. The mutant is not part of this PR. ## Validation performed Windows x64, Node 24.18.0 / npm 11.16.0, base bb266226707135ad9f181e6c3afd6af0ef62fb22: - npm run test:focused -- tests/boundary/filesystem/asarHeaderAdmission.test.ts: passed, 4 tests including compiled prerequisites. - Restored-source Vitest run: 4 passed after the deliberate failing mutation. - npm run check: passed, lint 0 errors / 932 repository warnings. - npm run verify:test-discovery: 963 files discovered exactly once. - git diff --check: passed. ## Compatibility, safety, and release Tests only; no dependencies, release metadata, migrations or runtime changes. This is a bounded deterministic corpus, not a general fuzzing service, full archive-parser proof or end-to-end performance benchmark. No native Windows-control or real-provider coverage is claimed. ## Before merge - [x] Coverage protects a concrete allocation/admission boundary. - [x] Real serializer and filesystem positive controls accompany negative cases. - [x] Mutation probe demonstrated a meaningful failing regression. - [x] No unrelated changes, generated artifacts or external samples included. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
bsakaguchi 2026-10-31 01:04:25 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#5159
No description provided.