Clarity needed in relation to Snapshot role and online vs offline
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Documentación
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Área
- documentation
Línea de trabajo
Compara las indicaciones sobre las claves de Snapshot en content/metadata.md y content/faq.md con la Specification citada en la issue. Primero establece qué indicación es la autoritativa y después actualiza la redacción conflictiva del sitio web para que las referencias coincidan. La tarea está terminada cuando la documentación de FAQ y de metadatos describa de forma coherente el almacenamiento de las claves de rol de Snapshot.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
At the moment, the website can't seem to make its mind up as to whether Snapshot role keys should be online or offline.
Really someone needs to decide once and for all and stick to it, instead of all this conflicting wording.
If we consider the Specification as the ultimate source of truth, then we are told:
All keys, except those for the timestamp and mirrors roles, should be stored securely offline
content/metadata.md seems to agree:
so that the Snapshot role's keys can be kept offline, and thus more secure
So far so good. But the FAQ content/faq.md is where you have the bouncing around. On one page we are told two different things...
Three places state online:
even sharing online keys (e.g., between the Timestamp and Snapshot roles)
In contrast, the Snapshot role is updated often, signed with an online key
The Timestamp and Snapshot roles can use online keys
And then we have a suggestion of offline for Snapshot:
separate keys should be used so that the Snapshot role’s keys can be kept offline, and thus in a more secure manner.
If we assume the Specification reflects the TUF design decision, then the rest of the website should be consistent.
- Lenguaje dominante
- HTML
- Estrellas
- 25
- Forks
- 46
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
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 theupdateframework/theupdateframework.io
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
theupdateframework/theupdateframework.io#184 · 1 comentario ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 84/100
theupdateframework/theupdateframework.io#183 · 3 comentarios ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
theupdateframework/theupdateframework.io#182 · 1 comentario ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 72/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Todos los issues de theupdateframework/theupdateframework.io
Issues similares
-
Link Checker ReportAbiertoautomated issue report
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
-
Dificultad 1/5 1-3 horas Aptitud para principiantes 88/100
supabase/agent-skills#611 ·
-
Dificultad 1/5 1-3 horas Aptitud para principiantes 75/100
isocpp/CppCoreGuidelines#2338 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 68/100
polka-codes/test#345 ·
Los mantenedores suelen responder en 1 día