Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

design spec_version updates

Aperta
  • Qualcosa non va?
#2,077 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
python
Ambito
security

Direzione di ricerca

Inizia leggendo l’issue #2040 e il comportamento esistente dei metadati di python-tuf e degli aggiornamenti del repository. Confronta le tre strategie di spec_version descritte qui, incluso il modo in cui le succinct delegations influenzano la compatibilità. Il lavoro è completato quando sono documentati chi imposta la versione, quali strumenti sono necessari e un design definito per determinare la spec_version minima supportata.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Python
Stelle
1.7k
Fork
304
Merge medio
1g 2h
PR unite (30g)
17

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di theupdateframework/python-tuf

Tutte le issue di theupdateframework/python-tuf

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.