Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

design spec_version updates

Ouverte
#2,077 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 10 jours

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Fonctionnalité
Clarté
À clarifier
Activité
À l'abandon
Stack technique
python
Domaine
security

Piste de recherche

Commencez par lire l’issue #2040 ainsi que le comportement existant des métadonnées de python-tuf et des mises à jour du dépôt. Comparez les trois stratégies de spec_version décrites ici, notamment la manière dont les succinct delegations influent sur la compatibilité. Le travail est terminé lorsque sont documentés l’acteur qui définit la version, les outils nécessaires et une conception arrêtée pour déterminer la spec_version minimale prise en charge.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Python
Étoiles
1.7k
Forks
304
Merge moyen
9 h 25 min
PR mergées (30 j)
14

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de theupdateframework/python-tuf

Toutes les issues de theupdateframework/python-tuf

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.