morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #8690] [Bug] Kuna verification updates reject snapshots from the same executable #7511

New issue

Open

opened 2026-11-03 00:30:25 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-11-03 00:30:25 +00:00

Owner

Originally created by @morluto on GitHub (Nov 2, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8690

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Evidence, artifacts, or reconstruction

Observed behavior

On the proposed 1.989 verification update (fc2ca7115), an existing 1.988 analysis snapshot fails to open even when selecting the same target and the same Kuna 1.988 executable that produced it. MCP open_binary returns evidence_integrity_mismatch for the profile digest.

Reproduction

On REA with 1.988 designated verified, analyze a Mach-O with Kuna 1.988 and close the session with a snapshot.
On the proposed update, reopen that snapshot against the same artifact and Kuna 1.988 executable.
The snapshot is rejected. This was observed once using an existing snapshot; other provider releases and formats were not tested.

Expected behavior

A change in REA's current release verification label should not alone make a snapshot from an otherwise identical producer and analysis profile inaccessible. Preserve historical verification facts and fail closed for actual analysis identity mismatches. The precise contract and migration design need investigation.

Impact and scope

An otherwise usable 1.988 snapshot cannot be reattached in the tested scenario; the existing recovery suggests running a fresh analysis. Whether Evidence can be imported separately was not tested. Broader impact is unknown.

REA version

fc2ca7115 (proposed 1.989 verification bump; based on 2cb29693c)

Runtime and platform

Node 24.22.1; macOS arm64; Kuna 1.988.

Target and artifact context

Source-owned arm64 Mach-O fixture, SHA-256 8698771cccb98f77e1282b76267c96f6699d86fee548e14c4afef6dd3d571517; target not executed.

Interface

MCP

Earliest failure stage

Setup or provider admission

Relevant output or evidence

evidence_integrity_mismatch: Analysis snapshot target, provider, or analysis profile does not match the requested binary. Details report different snapshot and selected profile digests. The saved profile has verified_release: true; the selected same executable is now unverified. Snapshot and selection used the same version, executable digest, command, jobs, and target.

Analysis or suspected cause

Source-derived: the Kuna provider puts verified_release in analysis profile parameters, and snapshot binding compares profile digests. Changing the verified-version policy changes that parameter even for an unchanged executable. See KunaProvider and snapshot binding. Whether other profile parameters or providers have a similar issue has not been audited.

@gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Evidence recovery and identity controls

On the same macOS host, I extracted the rejected snapshot's evidence_bundle JSON to a separate file, imported it using import_evidence_bundle, opened the same target with 1.988 without a snapshot, analyzed the function again, and exported the combined bundle. In both compact and full MCP schema profiles, the original Evidence record survived exactly with its historical verified_release: true; the new record had verified_release: false. This manual extraction is an observed Evidence recovery, not a supported snapshot replay or proof that cached workflow results are recoverable. The tested snapshot held one Evidence record and no cached query or workflow entries.

As an identity control, selecting Kuna 1.989 against that snapshot also produced evidence_integrity_mismatch, with differing provider version and profile digest. A fix must retain meaningful provider and result-affecting identity checks. Source inspection shows the profile digest commits all parameters; removing the verification field outright would itself change old profile digests. A migration or other explicit historical binding design remains unresolved.

Policy-independent profile experiment

An unmerged prototype removes verified_release from the Kuna analysis profile and puts an unverified-release warning on fresh observation limitations. It keeps the executable version and SHA-256 in the profile. On macOS arm64 with real Kuna 1.988 and compact stdio MCP, I saved a new-format snapshot while the prototype designated 1.988 verified, rebuilt the prototype designating 1.989 verified, and reopened the snapshot against the same executable and target. The profile digest stayed the same, the historical Evidence remained exactly equal as parsed JSON, and a fresh result had a distinct Evidence ID with the new unverified warning. The opposite policy transition also reopened and retained the historical warning. A different 1.989 executable was still rejected by provider/profile binding.

This does not restore existing snapshots: a pre-change 1.988 snapshot containing verified_release was rejected by the prototype even when the same executable was selected. Removing the field would impose a one-time incompatibility on existing Kuna snapshots; manual Evidence-bundle extraction remains separate from restoring replayable workflow entries. The experiment adds no compatibility path and does not establish a migration strategy. It also needs complete dossier/summary projection, both MCP profiles, tests, documentation and broader review before any integration. The prototype is local and uncommitted; it does not change #8691. Targets were read and not executed.

Directory resume and dossier projection controls

With the same unmerged policy-independent profile prototype, real Kuna 1.988 compact MCP exported five functions, changed the prototype's verified release, and resumed for five more using the same target/executable and output directory. The analysis-profile digest remained the same; resume skipped the original five and preserved each of their index records, including their then-current unverified warning, while the five new records had no warning. The reverse transition also worked: the five earlier verified records remained unchanged and the five new records carried the unverified warning. This covers one local Mach-O and two ten-function exports, not cross-version decompiler behavior or legacy directory compatibility.

The prototype is incomplete: in a real compact analyze_function control, its unverified warning appeared on the Evidence envelope, summary and retained pseudocode view, but not in the nested complete dossier's own limitations array. Any implementation must define and preserve warning ownership consistently rather than treating this experiment as a finished patch. Pre-existing snapshots still fail as described above.

Reviewable draft

Draft #8699 develops the policy-independent approach on top of #8691, adds the missing complete-dossier warning and documents the one-time mismatch for existing snapshots and resumable directories. It does not restore legacy snapshot bindings; the historical compatibility decision remains open. Real 1.988/1.989 controls and the tests are recorded on the PR.

Originally created by @morluto on GitHub (Nov 2, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8690 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Evidence, artifacts, or reconstruction ### Observed behavior On the proposed 1.989 verification update (`fc2ca7115`), an existing 1.988 analysis snapshot fails to open even when selecting the same target and the same Kuna 1.988 executable that produced it. MCP `open_binary` returns `evidence_integrity_mismatch` for the profile digest. ### Reproduction 1. On REA with 1.988 designated verified, analyze a Mach-O with Kuna 1.988 and close the session with a snapshot. 2. On the proposed update, reopen that snapshot against the same artifact and Kuna 1.988 executable. 3. The snapshot is rejected. This was observed once using an existing snapshot; other provider releases and formats were not tested. ### Expected behavior A change in REA's current release verification label should not alone make a snapshot from an otherwise identical producer and analysis profile inaccessible. Preserve historical verification facts and fail closed for actual analysis identity mismatches. The precise contract and migration design need investigation. ### Impact and scope An otherwise usable 1.988 snapshot cannot be reattached in the tested scenario; the existing recovery suggests running a fresh analysis. Whether Evidence can be imported separately was not tested. Broader impact is unknown. ### REA version `fc2ca7115` (proposed 1.989 verification bump; based on `2cb29693c`) ### Runtime and platform Node 24.22.1; macOS arm64; Kuna 1.988. ### Target and artifact context Source-owned arm64 Mach-O fixture, SHA-256 `8698771cccb98f77e1282b76267c96f6699d86fee548e14c4afef6dd3d571517`; target not executed. ### Interface MCP ### Earliest failure stage Setup or provider admission ### Relevant output or evidence `evidence_integrity_mismatch`: `Analysis snapshot target, provider, or analysis profile does not match the requested binary`. Details report different snapshot and selected profile digests. The saved profile has `verified_release: true`; the selected same executable is now unverified. Snapshot and selection used the same version, executable digest, command, jobs, and target. ### Analysis or suspected cause Source-derived: the Kuna provider puts `verified_release` in analysis profile parameters, and snapshot binding compares profile digests. Changing the verified-version policy changes that parameter even for an unchanged executable. See [KunaProvider](https://github.com/morluto/rea/blob/2cb29693c/src/kuna/KunaProvider.ts) and [snapshot binding](https://github.com/morluto/rea/blob/2cb29693c/src/domain/analysisSnapshot.ts). Whether other profile parameters or providers have a similar issue has not been audited. @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 ### Evidence recovery and identity controls On the same macOS host, I extracted the rejected snapshot's `evidence_bundle` JSON to a separate file, imported it using `import_evidence_bundle`, opened the same target with 1.988 without a snapshot, analyzed the function again, and exported the combined bundle. In both compact and full MCP schema profiles, the original Evidence record survived exactly with its historical `verified_release: true`; the new record had `verified_release: false`. This manual extraction is an observed Evidence recovery, not a supported snapshot replay or proof that cached workflow results are recoverable. The tested snapshot held one Evidence record and no cached query or workflow entries. As an identity control, selecting Kuna 1.989 against that snapshot also produced `evidence_integrity_mismatch`, with differing provider version and profile digest. A fix must retain meaningful provider and result-affecting identity checks. Source inspection shows the profile digest commits all parameters; removing the verification field outright would itself change old profile digests. A migration or other explicit historical binding design remains unresolved. ### Policy-independent profile experiment An unmerged prototype removes `verified_release` from the Kuna analysis profile and puts an unverified-release warning on fresh observation limitations. It keeps the executable version and SHA-256 in the profile. On macOS arm64 with real Kuna 1.988 and compact stdio MCP, I saved a new-format snapshot while the prototype designated 1.988 verified, rebuilt the prototype designating 1.989 verified, and reopened the snapshot against the same executable and target. The profile digest stayed the same, the historical Evidence remained exactly equal as parsed JSON, and a fresh result had a distinct Evidence ID with the new unverified warning. The opposite policy transition also reopened and retained the historical warning. A different 1.989 executable was still rejected by provider/profile binding. This does **not** restore existing snapshots: a pre-change 1.988 snapshot containing `verified_release` was rejected by the prototype even when the same executable was selected. Removing the field would impose a one-time incompatibility on existing Kuna snapshots; manual Evidence-bundle extraction remains separate from restoring replayable workflow entries. The experiment adds no compatibility path and does not establish a migration strategy. It also needs complete dossier/summary projection, both MCP profiles, tests, documentation and broader review before any integration. The prototype is local and uncommitted; it does not change #8691. Targets were read and not executed. ### Directory resume and dossier projection controls With the same unmerged policy-independent profile prototype, real Kuna 1.988 compact MCP exported five functions, changed the prototype's verified release, and resumed for five more using the same target/executable and output directory. The analysis-profile digest remained the same; resume skipped the original five and preserved each of their index records, including their then-current unverified warning, while the five new records had no warning. The reverse transition also worked: the five earlier verified records remained unchanged and the five new records carried the unverified warning. This covers one local Mach-O and two ten-function exports, not cross-version decompiler behavior or legacy directory compatibility. The prototype is incomplete: in a real compact `analyze_function` control, its unverified warning appeared on the Evidence envelope, summary and retained pseudocode view, but not in the nested complete dossier's own `limitations` array. Any implementation must define and preserve warning ownership consistently rather than treating this experiment as a finished patch. Pre-existing snapshots still fail as described above. ### Reviewable draft Draft #8699 develops the policy-independent approach on top of #8691, adds the missing complete-dossier warning and documents the one-time mismatch for existing snapshots and resumable directories. It does not restore legacy snapshot bindings; the historical compatibility decision remains open. Real 1.988/1.989 controls and the tests are recorded on the PR.

bsakaguchi added the

bug

triage

labels

2026-11-03 00:30:25 +00:00

bsakaguchi commented

2026-11-03 10:21:15 +00:00

Author

Owner

@BeqaKs commented on GitHub (Nov 3, 2026):

Closing as fixed on main by #8699. Stayed open because the PR referenced rather than closed it.

@BeqaKs commented on GitHub (Nov 3, 2026): Closing as fixed on main by #8699. Stayed open because the PR referenced rather than closed it.

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#7511

No description provided.

Rows
Columns