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

design spec_version updates

Abierto
#2,077 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 10 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
python
Área
security

Línea de trabajo

Comienza leyendo el issue #2040 y el comportamiento existente de los metadatos de python-tuf y de las actualizaciones del repositorio. Compara las tres estrategias de spec_version descritas aquí, incluido cómo afectan las succinct delegations a la compatibilidad. Se considera terminado cuando se haya documentado quién establece la versión, qué herramientas se necesitan y exista un diseño resuelto para determinar la spec_version mínima compatible.

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

Descripción

discussion enhancement repository

Since a incompatible spec version update seems to get more interest (see #2040), we should start with actually designing how spec version numbers are going to work... Who is responsible for setting the version and what tools exist to help there?

As an example, lets say that TUF spec decides that succinct delegations are an incompatible spec addition -- this is a reasonable decision as adding succinct delegations to a targets metadata makes it invalid for older clients. Let's say, this is spec version 2.0.0.

Assume python-tuf supports spec 2.0.0. Now repositories are going to have many reasonable choices. At least these exist:

  1. start using 2.0.0 in all new metadata files (but keep old ones as is even when the are resigned). This is what happens by default with current python-tuf: this leads to bugs as soon as
    • succinct delegations are added to existing metadata
    • new metadata is added that old clients should be able to access
  2. start using 2.0.0 in all metadata files whenever they get re-signed. Issues appear when:
    • any metadata that old clients should be able to access is resigned
  3. start using 2.0.0 in all metadata that contain succinct delegations but legacy version in all others, even newly created metadata -- this allows old clients to keep accessing any metadata that doesn't contain succinct delegations

The last one is arguably most useful but also quite tricky to implement, at least in python-tuf (likely a lot easier in the repository itself): it might be possible to write methods that scans the metadata structure and decides "what is the lowest spec version that this structure supports": this method could be used by the repository when it's updating expiry,version,etc metadata content to also set spec_version at that time.

Lenguaje dominante
Python
Estrellas
1.7k
Forks
304
Merge medio
9 h 25 min
PR fusionados (30 d)
14

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 theupdateframework/python-tuf

Todos los issues de theupdateframework/python-tuf

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.