Skip to content

fix(status): fail closed when the baseline cannot identify the binary - #3

Merged
rldyourmnd merged 1 commit into
mainfrom
fix/fail-closed-on-missing-executable-baseline
Aug 1, 2026
Merged

fix(status): fail closed when the baseline cannot identify the binary#3
rldyourmnd merged 1 commit into
mainfrom
fix/fail-closed-on-missing-executable-baseline

Conversation

@rldyourmnd

Copy link
Copy Markdown
Contributor

Problem

software-status reported current: true after the managed executable was replaced.

The check that would have caught it exists:

if binary_sha != executable_baseline.get("sha256"):
    drift.append("baseline_binary_sha256")

but the whole block sits behind if isinstance(executable_baseline, dict), and the baseline declares that object for only one of six assets:

asset executable baseline
darwin-arm64 present
darwin-x64, darwin-x64-baseline absent
linux-arm64, linux-x64, linux-x64-baseline absent

So on every Linux platform the strongest verification silently disappeared and status still answered current.

Why the manifest is not a substitute

binary_sha256 in software/mimocode.json is self-reported: the manifest sits beside the binary and is equally writable, so whoever replaced one replaced both. The private slice's stub does exactly that — writes a coherent manifest for a substituted binary — and was reported as current.

Change

A baseline that omits the extracted-binary identity cannot answer "is this the software we installed". Status now says so through baseline_executable_unavailable rather than skipping the question and returning current anyway.

This makes the five missing baselines visible instead of silently trusted. Populating them is vendor-observation work and is deliberately not bundled here.

status still never executes the managed binary — that property is unchanged and still asserted.

Verification

  • test_software_status_reports_stub_identity_drift_without_executing_mimo — was failing, now passes
  • test_software_status_never_executes_target_binary — was failing, now passes
  • full runtime-launch + software-lifecycle slice: 10 passed, 4 subtests passed
  • run_harnesses.py --module nddev-mimocode-app --lane platform --platform ubuntuPASS
  • cli-tools/validate_public_contracts.py — ok
  • ruff check / ruff format --check clean

Reviewer finding RVR-P2-007.

https://claude.ai/code/session_017fG88hR3mfP7YMFABzbKPB

software-status reported current=true after the managed executable was
replaced. The check that would have caught it does exist:

    if binary_sha != executable_baseline.get("sha256"):
        drift.append("baseline_binary_sha256")

but the whole block sits behind `if isinstance(executable_baseline, dict)`,
and only darwin-arm64 declares that object. The five remaining assets --
every Linux one among them -- have no `executable` baseline, so on those
platforms the strongest verification silently disappeared and status still
answered current.

The manifest cannot stand in for it. It lives beside the binary and is just as
writable, so whoever replaced one replaced both; the stub in the private slice
does exactly that and was reported as current.

A baseline that omits the extracted-binary identity cannot answer "is this the
software we installed", so status now says so through
`baseline_executable_unavailable` instead of skipping the question and
returning current anyway. This makes the five missing baselines visible rather
than silently trusted -- populating them is vendor-observation work.

Reviewer finding RVR-P2-007. status still never executes the binary.

Claude-Session: https://claude.ai/code/session_017fG88hR3mfP7YMFABzbKPB
@rldyourmnd
rldyourmnd merged commit 9856b13 into main Aug 1, 2026
9 checks passed
@rldyourmnd
rldyourmnd deleted the fix/fail-closed-on-missing-executable-baseline branch August 1, 2026 23:57
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