[GH-ISSUE #191] domain: validate process capture executable commitment against scenario projection #138

New issue

Closed

opened 2026-10-15 18:21:31 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-15 18:21:31 +00:00

Owner

Originally created by @morluto on GitHub (Jul 14, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/191

Problem

validateCommitments in src/domain/processCaptureValidation.ts has a no-op invariant check for the executable SHA-256 commitment.

Current code asserts:

require(manifest.scenario.executable_sha256 === manifest.executable_sha256,
  "manifest.executable_sha256", ...)

This always compares against itself and never verifies that the committed manifest executable hash is derived from the scenario projection. As a result, a corrupted manifest.executable_sha256 value can pass parseProcessCapture and be treated as trusted process-capture evidence.

Evidence

The check above is in validateCommitments in src/domain/processCaptureValidation.ts and is a tautology.
processCaptureSchema relies on validateProcessCapture for semantic checks used by parseProcessCapture, so malformed captures are not rejected there.
processCapture schema and process-identity helpers commit this field as executable_sha256 in the scenario projection (src/domain/processScenario.ts).

Reproduction

Build any process-capture object that satisfies schema and other checks.
Set manifest.scenario.executable_sha256 = "cafeb..." and set a different manifest.executable_sha256.
Call parseProcessCapture.
Because of the self-comparison, this mismatch is not detected as a validation issue.

Expected

validateCommitments should check that:

manifest.scenario.executable_sha256 === manifest.executable_sha256
and that this value is the committed executable projection from the scenario, not a user-controlled independent value.

Equivalent to other commitment checks already implemented for full_scenario_sha256, comparison_contract_sha256, etc.

Impact

Allows tampered process-capture manifests with mismatched executable commitments to be considered valid, weakening evidence integrity guarantees.

Suggested fix

Replace the tautological condition with a real comparison and, if needed, a dedicated digest calculation of the scenario commitment including executable hash consistency (for example via processScenarioCommitment semantics).

Originally created by @morluto on GitHub (Jul 14, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/191 ## Problem `validateCommitments` in `src/domain/processCaptureValidation.ts` has a no-op invariant check for the executable SHA-256 commitment. Current code asserts: ```ts require(manifest.scenario.executable_sha256 === manifest.executable_sha256, "manifest.executable_sha256", ...) ``` This always compares against itself and never verifies that the committed manifest executable hash is derived from the scenario projection. As a result, a corrupted `manifest.executable_sha256` value can pass `parseProcessCapture` and be treated as trusted process-capture evidence. ## Evidence - The check above is in `validateCommitments` in `src/domain/processCaptureValidation.ts` and is a tautology. - `processCaptureSchema` relies on `validateProcessCapture` for semantic checks used by `parseProcessCapture`, so malformed captures are not rejected there. - `processCapture` schema and process-identity helpers commit this field as `executable_sha256` in the scenario projection (`src/domain/processScenario.ts`). ## Reproduction 1. Build any process-capture object that satisfies schema and other checks. 2. Set `manifest.scenario.executable_sha256 = "cafeb..."` and set a different `manifest.executable_sha256`. 3. Call `parseProcessCapture`. 4. Because of the self-comparison, this mismatch is not detected as a validation issue. ## Expected `validateCommitments` should check that: - `manifest.scenario.executable_sha256 === manifest.executable_sha256` - and that this value is the committed executable projection from the scenario, not a user-controlled independent value. Equivalent to other commitment checks already implemented for `full_scenario_sha256`, `comparison_contract_sha256`, etc. ## Impact Allows tampered process-capture manifests with mismatched executable commitments to be considered valid, weakening evidence integrity guarantees. ## Suggested fix Replace the tautological condition with a real comparison and, if needed, a dedicated digest calculation of the scenario commitment including executable hash consistency (for example via `processScenarioCommitment` semantics).

bsakaguchi

2026-10-15 18:21:31 +00:00

closed this issue
added the
area: runtime

enhancement
labels

bsakaguchi commented

2026-10-15 18:21:33 +00:00

Author

Owner

@N0zoM1z0 commented on GitHub (Jul 14, 2026):

Triage on current main (6a3fd5b): this report is not reproducible. Since ac78de0, the invariant compares manifest.scenario.executable_sha256 with manifest.executable_sha256; it is not a self-comparison. The process-capture regression rejects altered v4 commitments and accepts canonical key reordering passes in the full suite.

@N0zoM1z0 commented on GitHub (Jul 14, 2026): Triage on current `main` (`6a3fd5b`): this report is not reproducible. Since `ac78de0`, the invariant compares `manifest.scenario.executable_sha256` with `manifest.executable_sha256`; it is not a self-comparison. The process-capture regression `rejects altered v4 commitments and accepts canonical key reordering` passes in the full suite.

bsakaguchi referenced this issue

2026-10-16 21:11:48 +00:00

[PR #203] [MERGED] fix: resolve triaged correctness issues #1854

bsakaguchi added

enhancement

and removed

enhancement

labels

2026-10-31 00:28:45 +00:00