Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#1,406 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
cryptography, security

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
Python
Estrellas
0
Forks
6
Merge medio
1 d 23 h
PR fusionados (30 d)
134

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de PolicyEngine/microcosm

Todos los issues de PolicyEngine/microcosm

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.