Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

verify_chain: judge revocation by snapshot membership while windows are judged at at_time

Aperta
  • Qualcosa non va?
#263 4 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
1-2 giorni
Idoneità per principianti
48/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
python
Ambito
authentication, security

Direzione di ricerca

Start by reading the implementation and tests for verify_chain and effective_revocation, then trace how _check_revocation handles authority and snapshot membership. Decide which proposed public API fits the existing interface while preserving the current default, and add coverage for a snapshot statement whose issued_at is later than at_time. Done means the public API supports the log-order reading, documents that the caller supplies the exact snapshot, and the existing behavior remains covered.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement needs-review:HIGH

Problem statement

An auditor that replays a past decision from a transparency log needs two different clocks. Validity windows are judged at the decision time (at_time). Revocation is judged by log order: the snapshot holds exactly the statements the log published before the receipt, so every statement in it should count, whatever its issued_at says.

Today verify_chain(at_time=T, revocations=S) passes at_time=T on to effective_revocation, which skips statements with issued_at > T. A statement logged before the receipt, but stamped later by the revoker's clock, is ignored. The only way to get the log-order reading is to run verify_chain(..., revocations=None) and then the private _check_revocation(chain, S, at_time=None, now=T, max_staleness=None). That is what the MUSUBI companion does now (horizon-shield workers/hs-ledger/nenrin/musubi-v0/ca2a-companion-v0/companion_v0.py, _ca2a, pinned to ca2a-runtime 0.4.0). A private call will break on refactors that never touch its reading.

Proposed solution

Either of these, with today's default unchanged:

  1. A keyword on verify_chain, for example revocation_at_time, defaulting to at_time, where None means every statement in the supplied snapshot is in force.
  2. A public check_revocation(chain, revocations, *, at_time=None, now, max_staleness=None) with the semantics _check_revocation has now, documented as valid only on a chain whose structure has already verified.

Alternatives considered

  • Re-implementing the authority walk in the companion. Rejected: it would drift from cA2A's own rule that a delegate cannot revoke the grant it received.
  • Rewriting issued_at in the snapshot. Rejected: it changes signed statements.

Security/TEE impact

None on the TEE boundary or attestation flow. The new reading only counts more revocations, never fewer. When it is used, the caller asserts that the snapshot is exactly the set in force, and the docstring should say the caller owns that.

Spec alignment

No trace-spec change required.

Context: agentrust-io/.github discussion #65. Once this ships, the integrations entry switches to it and drops the 0.4.0 pin.

Lingua principale
Python
Stelle
9
Fork
14
Merge medio
17h 24m
PR unite (30g)
56

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di agentrust-io/ca2a

Tutte le issue di agentrust-io/ca2a

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.