You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
ucan: verify_chain never anchors the chain root to the resource owner #501
verify_chain (crates/gitlawb-core/src/ucan.rs:252-292) proves only self-consistency. A presenter can self-issue a root token (iss=me, aud=me, att=[git/push on Alice's repo]) and delegate from it; every check passes because every key is the attacker's. The node's validate_ucan_chain (auth/mod.rs:269-309) adds only iss == HTTP signer and aud == node, both of which the attacker controls.
Status: latent. ucan.can() gates nothing in the node today and push is owner-only, but the doc comment reserves exactly the extension that would activate it.
Distinct from #425 (constraints are ignored) and #467 (verification budget): this is about the chain root not being anchored to the resource owner.
Fix: before any can()-gated route ships, require the chain root's issuer to be the server-recorded repo owner (or a node-issued bootstrap token). Also check the ucan version field on verify, which is never read, and cap proof-chain recursion.
Open PR #331 already implements the fix asked for here: it anchors the UCAN chain root to the repository owner on the push path, which is the route where can() first goes live. Linking so the two stay paired.
Activity
beardthelion commentedon Oct 2, 2026
Open PR #331 already implements the fix asked for here: it anchors the UCAN chain root to the repository owner on the push path, which is the route where can() first goes live. Linking so the two stay paired.