Sign a pack file and verify the signature before use
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
- 42/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- go
- Área
- cryptography, security
Línea de trabajo
Start by reading the audit command key tooling and the SDK pack-loading entry point; the issue does not name specific files or tests. Trace how the runtime reads pack versions and hashes pack bytes, then identify the existing signing conventions. Done means detached sign and verify commands, SDK verification before load, documented key expectations and signature limits, and refusals for every listed invalid-signature case across supported pack versions.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Observed. A pack's identity is the SHA-256 of its file bytes, and a lock pins it. There is no command that signs a pack or verifies a signature over it; signing exists for audit trails and for the release binaries. A party that publishes packs to others has no stated convention to follow, and each reader invents one.
Ask. Commands that produce and check a detached signature over a pack's file bytes, using the key tooling the audit commands already have, and the matching SDK call to verify before load. No canonical form of a pack is introduced: the signature is over the bytes the digest is over. The doc states the convention (file name of the signature, what is signed, how a verifier is told which key to expect) and what a valid signature establishes and does not.
Acceptance. Sign, verify, and refusals for: changed bytes, another key, a truncated or malformed signature file, an unexpected key. Works on a pack of any spec version the runtime reads.
- Lenguaje dominante
- Go
- Estrellas
- 2
- Forks
- 6
- Merge medio
- 2 h 1 min
- PR fusionados (30 d)
- 69
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de Judgment-Pack/judgment-pack-runtime
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Judgment-Pack/judgment-pack-runtime#390 ·
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 5/5 Más de una semana Aptitud para principiantes 45/100
Judgment-Pack/judgment-pack-runtime#392 ·
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 3/5 1-2 días Aptitud para principiantes 68/100
Judgment-Pack/judgment-pack-runtime#389 ·
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 3/5 1-2 días Aptitud para principiantes 57/100
Judgment-Pack/judgment-pack-runtime#388 ·
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
Judgment-Pack/judgment-pack-runtime#363 ·
Los mantenedores suelen responder en 1 día
Todos los issues de Judgment-Pack/judgment-pack-runtime
Issues similares
-
0.kind: bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
triage/needs-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
cozystack/cozystack#5300 · 1 reacción ·
Los mantenedores suelen responder en 2 días
-
bug go
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
teradata-labs/loom#665 ·
Los mantenedores suelen responder en 1 día
-
Improve DB UIAbiertoenhancement ui/ux
Dificultad 2/5 1-3 horas Aptitud para principiantes 64/100
jbigler/railswitch#222 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 73/100
fullsend-ai/fullsend#9404 ·
Los mantenedores suelen responder en 1 día