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

Sign UK gate reports with Ed25519 so anyone can verify a cut

Aperta
  • Qualcosa non va?
#1,406 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python
Ambito
cryptography, security

Direzione di ricerca

Start with docs/uk-cut-anyone.md § Signing keys and the registry introduced by #1405, then trace how UK gate reports, release-cut certifications, and dense gate reports are signed and verified. Resolve the migration, dependency, and retirement questions before implementation. Done means reports use Ed25519 public-key verification, with a documented decision for existing HMAC-signed cuts and retired keys.

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

Descrizione

UK gate reports, release-cut certifications and dense gate reports are signed with HMAC-SHA256. The keys are registered by fingerprint in microcosm.data.gate_signing_keys, from #1405. HMAC is symmetric, so the signature can't do some of what a certificate should. Vahid set out the limits in his review of #1405:

  • Verifying needs the secret. Whoever can verify a cut can also sign one. A "certified" cut is its key holder vouching for their own reports. policyengine.py and users downstream rely on Hugging Face write access and the registry, not on a signature they can check.
  • Retirement can't be checked. retired_on is only recorded. Whoever still holds a retired key can mint reports that verify.
  • Revocation is local. It binds only checkouts and wheels that include the revoking commit.

#1405 documents these limits in docs/uk-cut-anyone.md § Signing keys.

Proposal

Sign with Ed25519 instead. The registry would hold each builder's public key in place of a fingerprint, signers would keep the private key, and anyone with the repository could verify a cut, including policyengine.py at certification time.

Open questions:

  • Migration. Keep HMAC verification for the cuts already signed (66bf0e29… and the team key dd31e325…), or re-sign them?
  • Dependency. Which library? The standard library has no Ed25519, and the workspace doesn't lock cryptography or PyNaCl today, so this adds one to microcosm-data.
  • Retirement. Should verifiers compare a report's signing time with retired_on? That would need a trusted time source, or a signed release log.

🤖 Generated with Claude Code

Lingua principale
Python
Stelle
0
Fork
6
Merge medio
1g 20h
PR unite (30g)
132

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 PolicyEngine/microcosm

Tutte le issue di PolicyEngine/microcosm

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.