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

During root update, should we purge trusted timestamp/snapshot after key rotation earlier in the process?

Aperta
  • Qualcosa non va?
#318 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Documentazione
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Ambito
documentation, security

Direzione di ricerca

Inizia dalla sezione «Update Root» della specifica v1.0.34, in particolare dai passaggi 7–11 e dal paper Mercury collegato. Confronta l’ordine proposto per l’eliminazione del timestamp e dello snapshot con lo scenario di errore descritto; il lavoro è completato quando è stata presa una decisione e sono state registrate la modifica concordata alla specifica o la relativa motivazione.

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

Descrizione

I finally had a little time to work on rust-tuf, and I noticed in 1.0.34 the spec states that we purge the timestamp/snapshot metadata on key rotation:

...

  1. Set the trusted root metadata file to the new root metadata file.

  2. Persist root metadata. The client MUST write the file to non-volatile storage as FILENAME.EXT (e.g. root.json).

  3. Repeat steps 5.3.2 to 5.3.9

  4. Check for a freeze attack. The expiration timestamp in the trusted root metadata file MUST be higher than the fixed update start time. If the trusted root metadata file has expired, abort the update cycle, report the potential freeze attack.

  5. If the timestamp and / or snapshot keys have been rotated, then delete the trusted timestamp and snapshot metadata files. This is done in order to recover from fast-forward attacks after the repository has been compromised and recovered. A fast-forward attack happens when attackers arbitrarily increase the version numbers of: (1) the timestamp metadata, (2) the snapshot metadata, and / or (3) the targets, or a delegated targets, metadata file in the snapshot metadata. Please see the Mercury paper for more details.

I'm wondering if we should move step 11 to right after (8) we persist root metadata, rather than as the last step. That way if we run into an error during the root update cycle, such as if the one of the following root metadata is malformed we won't have a mix of a new trusted root with old metadata?

Lingua principale
Python
Stelle
405
Fork
59
Merge medio
13g 21h
PR unite (30g)
2

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

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/specification

Tutte le issue di theupdateframework/specification

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.