Skip to content

[docs] Record + dismiss tough<0.22 Dependabot advisories (no upstream fix)#266

Merged
paulirotta merged 1 commit into
mainfrom
chore/security-tough-advisory
Jun 18, 2026
Merged

[docs] Record + dismiss tough<0.22 Dependabot advisories (no upstream fix)#266
paulirotta merged 1 commit into
mainfrom
chore/security-tough-advisory

Conversation

@paulirotta

Copy link
Copy Markdown
Owner

Addresses the 2 high-severity Dependabot alerts flagged on main. Both are the same cratetough < 0.22.0:

  • Missing Delegated Metadata Validation
  • Delegated Roles have a Signature Threshold Bypass

Why there's no version-bump fix

Dependency path: ahma_mcp → sigstore-verification 0.2.8 → sigstore 0.13.0 → tough 0.21.0.

tough 0.22 (the fix) only arrives via sigstore 0.14 (tough ^0.22). Reaching it needs sigstore-verification to depend on sigstore ^0.14, but no published version does0.2.8 (latest) still pins sigstore ^0.13tough ^0.21. A cargo update/--precise bump is rejected by the resolver, and [patch.crates-io] can't satisfy ^0.21 with 0.22.x. Forcing it would mean vendoring/forking sigstore-verification onto sigstore 0.14 (0.13→0.14 API adaptation + maintained third-party code).

Why the residual risk is tolerable

tough is reachable only through the opt-in self-update attestation path — ahma update / ahma verifyupdate::verify::verify_artifactsigstore_verification::verify_github_attestation. It is not in the MCP server, the sandbox, or any normal runtime path. Exploiting it requires subverting the Sigstore public-good TUF CDN at the moment a user runs an attested update. Release artifacts are also checksum-verified independently.

What this PR does

  • Adds docs/security-advisories.md — a register of accepted/tracked advisories with the full analysis, tolerable-risk rationale, and the exact closing condition (bump once sigstore-verification adopts sigstore ^0.14).
  • Cross-references it from docs/release-signing.md.
  • The two Dependabot alerts (Feature/test up #9, Feature/concurrency #10) have been dismissed as tolerable_risk via the API, each pointing at the doc. 0 open alerts remain.

No code or dependency changes — this is a documented, tracked acceptance, to be closed automatically when upstream ships sigstore-verification on sigstore 0.14.

🤖 Generated with Claude Code

The two high-severity Dependabot alerts are both `tough` < 0.22.0 (TUF
delegated-metadata validation + signature-threshold bypass), pulled in
transitively via sigstore-verification 0.2.8 -> sigstore 0.13.0.

There is no clean version-bump fix: tough 0.22 only arrives via sigstore
0.14, and no published sigstore-verification depends on sigstore ^0.14
(0.2.8, latest, still pins ^0.13 -> tough ^0.21). The vulnerable code is
reachable only through the opt-in self-update attestation path
(`ahma update` / `ahma verify`), never the MCP server or sandbox runtime.

- Add docs/security-advisories.md: a register of accepted/tracked
  third-party advisories, with the full dependency analysis, why the
  residual risk is tolerable, and the exact closing condition (bump once
  sigstore-verification adopts sigstore ^0.14).
- Cross-reference it from docs/release-signing.md.
- Dismiss alerts #9 and #10 as tolerable_risk, pointing at the doc.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
EOF 2>&1
@paulirotta paulirotta merged commit 39c4e9f into main Jun 18, 2026
11 checks passed
@paulirotta paulirotta deleted the chore/security-tough-advisory branch June 18, 2026 11:03
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