[GH-ISSUE #8534] [Bug] Ghidra snapshot verifier expects obsolete profile-mismatch wording #6639

Open
opened 2026-11-01 21:12:51 +00:00 by bsakaguchi · 0 comments
Owner

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

Before submitting

  • I searched open and closed issues and pull requests for related reports.
  • I removed credentials, private paths, and sensitive target data.

Area

Tests or verification

Observed behavior

The real Ghidra reference-snapshot verifier rejects the current correct structured profile-mismatch response because it expects details.reason to contain the old literal profile_mismatch. Its next remediation assertion also expects old wording. As a result the verifier stops even though the intended fail-closed mismatch was returned.

Reproduction

On macOS arm64 with Node 24.22.1, Ghidra 12.1.4 and JDK 21, run npm run verify:ghidra:cross-format at REA #8531 head d232c43d99dbc3811b0f2fa9cd2488bfc0aac318 in a disposable checkout after applying only the verifier files from #8491 2bf92eb91964d136256116badbf50001dfabedf0 and #8381 64e42396fed526cd127aa1009c89b50a3959c741. These separate verifier changes get past an earlier known failure; they are not part of the production fix. The lane then stops in verifyLegacyGhidraReferenceSnapshot with AssertionError, expected /profile_mismatch/, actual Analysis snapshot target, provider, or analysis profile does not match the requested binary.

Expected behavior

Validate the stable error code and the structured details.binding_mismatch.profile_digest values against the generated legacy and selected profiles. Preserve the existing active-session and fresh-analysis checks, and check recovery without requiring superseded prose. #8432 intentionally changed the diagnostic wording and added structured mismatch details.

Impact and scope

A real-provider verification run fails before later controls, potentially obscuring regressions. The observed failure used one host and the combined verifier checkout described above; a clean-main full lane was not separately established to reach this assertion because #8172 blocks it earlier. The fixture was source-owned and unexecuted.

REA version

#8531 head d232c43d99dbc3811b0f2fa9cd2488bfc0aac318 plus the two verifier-only files noted above.

Runtime and platform

Node 24.22.1, macOS arm64, Ghidra 12.1.4 and JDK 21.

Target and artifact context

Source-built verifier fixture and generated legacy snapshot; target not executed.

Interface

MCP.

Earliest failure stage

Tests or verification.

Relevant output or evidence

requireMcpToolError produced code: evidence_integrity_mismatch; the verifier failed comparing details.reason against /profile_mismatch/. The existing verifier source then matches remediation against without this snapshot.*fresh snapshot; real current profile mismatch uses run analysis without it and save a fresh snapshot instead. The actual structured fields can carry both profile digests.

Typed outcome or recovery expected

Check binding_mismatch.profile_digest.snapshot and .selected against the independently constructed expected profile identities; preserve active session and CLI/MCP parity checks.

Analysis or suspected cause

Source-derived: scripts/lib/ghidra-reference-snapshot-e2e.mjs still asserts the old error prose. #8432 replaced the generic profile mismatch text with structured target/provider/profile mismatch details. This is a test-contract drift, not evidence that REA admitted the incompatible snapshot.

Additional context

Related #8172 / #8491 and #8380 / #8381 address separate earlier verifier obstacles. @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Combined real-provider verification on 2026-11-02

On macOS arm64 with Ghidra 12.1.4 and JDK 21, npm run verify:ghidra passed in a temporary checkout of #8379 0212145b0 with verifier-only changes from #8541 2bf92eb9, #8381 64e42396, #8536 78b6c662 and #8578 dd281594 applied. The report recorded 439 successful and 52 rejected boundary calls, regex recovery, legacy snapshot rejection, mutation snapshot lifecycle, distinct project identity refusals, complete cleanup, verified process lineage and no descendants. This is a combined run, not a clean pass of this issue’s PR or main.

Originally created by @morluto on GitHub (Nov 1, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8534 ### Before submitting - [x] I searched open and closed issues and pull requests for related reports. - [x] I removed credentials, private paths, and sensitive target data. ### Area Tests or verification ### Observed behavior The real Ghidra reference-snapshot verifier rejects the current correct structured profile-mismatch response because it expects `details.reason` to contain the old literal `profile_mismatch`. Its next remediation assertion also expects old wording. As a result the verifier stops even though the intended fail-closed mismatch was returned. ### Reproduction On macOS arm64 with Node 24.22.1, Ghidra 12.1.4 and JDK 21, run `npm run verify:ghidra:cross-format` at REA #8531 head `d232c43d99dbc3811b0f2fa9cd2488bfc0aac318` in a disposable checkout after applying only the verifier files from #8491 `2bf92eb91964d136256116badbf50001dfabedf0` and #8381 `64e42396fed526cd127aa1009c89b50a3959c741`. These separate verifier changes get past an earlier known failure; they are not part of the production fix. The lane then stops in `verifyLegacyGhidraReferenceSnapshot` with `AssertionError`, expected `/profile_mismatch/`, actual `Analysis snapshot target, provider, or analysis profile does not match the requested binary`. ### Expected behavior Validate the stable error code and the structured `details.binding_mismatch.profile_digest` values against the generated legacy and selected profiles. Preserve the existing active-session and fresh-analysis checks, and check recovery without requiring superseded prose. #8432 intentionally changed the diagnostic wording and added structured mismatch details. ### Impact and scope A real-provider verification run fails before later controls, potentially obscuring regressions. The observed failure used one host and the combined verifier checkout described above; a clean-main full lane was not separately established to reach this assertion because #8172 blocks it earlier. The fixture was source-owned and unexecuted. ### REA version #8531 head `d232c43d99dbc3811b0f2fa9cd2488bfc0aac318` plus the two verifier-only files noted above. ### Runtime and platform Node 24.22.1, macOS arm64, Ghidra 12.1.4 and JDK 21. ### Target and artifact context Source-built verifier fixture and generated legacy snapshot; target not executed. ### Interface MCP. ### Earliest failure stage Tests or verification. ### Relevant output or evidence `requireMcpToolError` produced `code: evidence_integrity_mismatch`; the verifier failed comparing `details.reason` against `/profile_mismatch/`. The existing verifier source then matches remediation against `without this snapshot.*fresh snapshot`; real current profile mismatch uses `run analysis without it and save a fresh snapshot` instead. The actual structured fields can carry both profile digests. ### Typed outcome or recovery expected Check `binding_mismatch.profile_digest.snapshot` and `.selected` against the independently constructed expected profile identities; preserve active session and CLI/MCP parity checks. ### Analysis or suspected cause Source-derived: `scripts/lib/ghidra-reference-snapshot-e2e.mjs` still asserts the old error prose. #8432 replaced the generic profile mismatch text with structured target/provider/profile mismatch details. This is a test-contract drift, not evidence that REA admitted the incompatible snapshot. ### Additional context Related #8172 / #8491 and #8380 / #8381 address separate earlier verifier obstacles. @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 ### Combined real-provider verification on 2026-11-02 On macOS arm64 with Ghidra 12.1.4 and JDK 21, `npm run verify:ghidra` passed in a temporary checkout of #8379 `0212145b0` with verifier-only changes from #8541 `2bf92eb9`, #8381 `64e42396`, #8536 `78b6c662` and #8578 `dd281594` applied. The report recorded 439 successful and 52 rejected boundary calls, regex recovery, legacy snapshot rejection, mutation snapshot lifecycle, distinct project identity refusals, complete cleanup, verified process lineage and no descendants. This is a combined run, not a clean pass of this issue’s PR or main.
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#6639
No description provided.