`Repository.writeall()` does not "write all" and may leave repo in inconsistent state

[lukpueh]

Description of issue or feature request:

The name and docstring of Repository.writeall()-classmethod and its commented use in the tuf tutorial, suggest that it writes all the metadata that needs to be written upon a metadata change, when in practice it only writes metadata that is marked as dirty.

This may leave the repository metadata in an inconsistent state, as is the case in above linked tutorial part.

Current behavior:

writeall only writes metadata that is marked as dirty, ignoring metadata interdependencies, i.e. timestamp needs to be re-written if snapshot changes, snapshot needs to be rewritten if targets or delegated targets changes, which may leave a repository in an inconsistent state.

Expected behavior:
Two options are conceivable:

• Update documentation but above all the tutorial to clarify that writeall might require a prior call to mark_dirty (I will add a quick fix in Fix TUTORIAL.md and add regression testing for future issues #775)

• Update writeall to indeed write all the metadata that is required to be written upon any metadata change (preferred solution).

[JustinCappos]

I agree with the second option. Let's make writeall actually write all!

[lukpueh]

Thanks for you comment, @JustinCappos! Can we briefly together look at the metadata inter-dependencies to make sure that writeall will indeed write all?

As far as I can see the following inter-dependencies exist:

• a change of keys in a delegating role, i.e. root or any delegating targets role, requires to bump the version and renew the signature of the delegated role, whose key was changed:
  • (change root keys in root --> bump version and re-sign root)
  • change timestamp key in root --> bump version and re-sign timestamp
  • change snapshot key in root --> bump version and re-sign snapshot
  • change targets key in root --> bump version and re-sign targets
  • change delegated targets key in delegating targets --> bump version and re-sign delegated targets
• any change in targets or delegated targets (including above) requires to update the relevant targets version number (and optionally its length and hashes) in snapshot, bump snapshot's own version number, and renew snapshot's signature
• any change in snapshot (including above) requires to update snapshot's version number in timestamp, bump timestamp's own version number, and renew timestamp's signature

Note how above rules may create longer update chains, e.g. changing targets keys in root, must re-write targets, which in turn must re-write snapshot, which in turn must re-write timestamp.

Can someone double-check if this list is correct and comprehensive? cc @mnm678, @SantiagoTorres, @trishankatdatadog.

[trishankatdatadog]

@lukpueh Sounds about right to me. Way back then, we used to write everything to disk regardless of whether a role metadata file was "dirty" or not. @SantiagoTorres and I noticed this in our PyPI experiments, and we asked to write only dirty files going forward. I'm guessing there are bugs in that implementation logic.

[woodruffw]

Submitting my support for this as the PEP 458 implementor -- having to manually mark things as dirty makes it easy to make small mistakes.