Skip to content

fix: restrict anchor_entity_id to trusted findings; re-vendor wardline taint golden#80

Merged
tachyon-beep merged 2 commits into
mainfrom
fix/anchor-entity-id-boundary-and-wardline-revendor
Jun 29, 2026
Merged

fix: restrict anchor_entity_id to trusted findings; re-vendor wardline taint golden#80
tachyon-beep merged 2 commits into
mainfrom
fix/anchor-entity-id-boundary-and-wardline-revendor

Conversation

@tachyon-beep

Copy link
Copy Markdown
Collaborator

Addresses two P2 review findings.

1. Restrict anchor_entity_id to trusted findings (trust boundary)

validate_plugin_finding copied all plugin metadata through verbatim and overwrote only anchor_file_path. The host-reserved anchor_entity_id key — consumed by the cli's host_finding_anchor_id, taken verbatim as findings.entity_id and FK-enforced at insert — was not protected. A plugin-reported finding could therefore set it to override the trusted file anchor:

  • a nonexistent id hard-failed the whole analyze run on the findings FK;
  • an existing id silently mis-associated the finding.

Fix: strip the host-reserved anchor_entity_id at the plugin boundary (symmetric with the already host-overwritten anchor_file_path). The only legitimate producer — the host's duplicate-locator finding (clarion-48af930f2a) — builds its HostFinding directly and bypasses this path, so it is unaffected. No subcode-gate at the consumer (avoids fragile cross-crate string-coupling).

Tests:

  • unit (host_validate.rs): reserved key stripped, anchor_file_path still injected, other plugin metadata preserved.
  • e2e regression (analyze_hardening.rs) via a new opt-in fixture-plugin switch: a plugin emits a forged anchor_entity_id; the run completes and the finding falls back to a real anchor. Reverting the strip reproduces the exact FOREIGN KEY constraint failed run hard-fail.

2. Re-vendor the Wardline taint golden

The Layer-2 drift recheck in wardline_taint_fact_conformance_oracle reds when the sibling Wardline repo is present: the vendored golden's svc.leaky finding fingerprint (9a291cac) was stale. The committed Wardline authority advanced it to 242d8565 (via merge 808e4978 on release/consolidation-2026-06-26); only that one field differs.

Fix: re-vendor the golden byte-identical (cmp clean) and recompute the Layer-1 byte-pin GOLDEN_BLAKE3. This fixes the real drift rather than weakening the recheck to opt-in. Both sibling-present (5/5) and skip-clean (CI absent) paths pass.

Verification

Full CI floor green locally: fmt, clippy -D warnings, build, nextest (1977 passed, 2 skipped, run with WARDLINE_REPO set), doc -D warnings, deny check.

🤖 Generated with Claude Code

tachyon-beep and others added 2 commits June 29, 2026 20:52
…etadata

validate_plugin_finding passed all plugin metadata through verbatim and
overwrote only anchor_file_path. The host-reserved anchor_entity_id key —
consumed by the cli's host_finding_anchor_id, taken verbatim as
findings.entity_id and FK-enforced at insert — was NOT protected: a
plugin-reported finding could set it to override the trusted file anchor.
A nonexistent id hard-failed the whole analyze run on the findings FK; an
existing id silently mis-associated the finding.

Strip anchor_entity_id at the plugin boundary (symmetric with the
host-overwritten anchor_file_path). The legitimate producer — the host's
duplicate-locator finding (clarion-48af930f2a) — builds its HostFinding
directly and bypasses this path, so it is unaffected.

Tests:
- unit: the reserved key is stripped, anchor_file_path is still injected,
  and other plugin metadata is preserved.
- e2e regression: a new opt-in fixture-plugin switch
  (LOOMWEAVE_FIXTURE_FINDING_FORGED_ANCHOR) emits a finding with a forged
  anchor_entity_id; the run completes and the finding falls back to a real
  anchor. Reverting the strip reproduces the FOREIGN KEY constraint hard-fail.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The Layer-2 drift recheck in wardline_taint_fact_conformance_oracle reds
when the sibling Wardline repo is present at the default /home/john/wardline:
the vendored golden's svc.leaky finding fingerprint (9a291cac) was stale.
The committed Wardline authority advanced it to 242d8565 (via merge 808e4978
on release/consolidation-2026-06-26); only that one field differs.

Re-vendor the golden byte-identical (cmp clean) and recompute the Layer-1
byte-pin GOLDEN_BLAKE3. This fixes the real drift rather than weakening the
recheck to opt-in. Both the sibling-present (5/5) and skip-clean (CI absent)
paths pass.

Provenance: the authority is Wardline's release/consolidation-2026-06-26
branch; if that branch re-stamps the fingerprint before landing, Layer-2 will
red again — that is the recheck working as designed.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@tachyon-beep tachyon-beep merged commit de3950e into main Jun 29, 2026
4 checks passed
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