Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

design spec_version updates

Offen
  • Stimmt etwas nicht?
#2,077 2 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
25/100
Issue-Typ
Feature
Klarheit
Muss geklärt werden
Aktivitätsstatus
Veraltet
Tech-Stack
python
Bereich
security

Rechercherichtung

Beginne mit dem Lesen von Issue #2040 sowie des vorhandenen python-tuf-Metadaten- und Repository-Update-Verhaltens. Vergleiche die drei hier beschriebenen Strategien für spec_version, einschließlich der Auswirkungen von succinct delegations auf die Kompatibilität. Als abgeschlossen gilt die Aufgabe, wenn dokumentiert ist, wer die Version festlegt, welche Werkzeuge benötigt werden und ein geklärtes Design zur Bestimmung der niedrigsten unterstützten spec_version vorliegt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
Python
Sterne
1.7k
Forks
306
Ø Merge
9 Std. 39 Min.
Gemergte PRs (30 T.)
12

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus theupdateframework/python-tuf

Alle Issues in theupdateframework/python-tuf

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.