File remaining design/prototype/implementation issues

[jku]

Filing issues for everything feels like a daunting task so I'm writing things down here to start with:

• define TUF metadata layout define TUF metadata layout #4
• publish metadata (at least initially) setup metadata publishing  #5
• Implement downloader client -- can be done as soon as there's working metadata
• prototype repository library as documented in https://github.com/theupdateframework/python-tuf/blob/develop/docs/repository-library-design.md -- probably at least partly in this repo, partly in python-tuf
• prototype developer tooling: this should be something like a downloader client (in that it uses trusted metadata from the remote repository) but it should also be able to work with not-completely-trusted data: targets files that are not yet fully signed and are not yet part of the snapshot -- this could mean a modified version of ngclient._internal.trusted_metadata_set ?
• Design/prototype timestamp/snapshot functionality using the repository library: this should be fairly easy, there's a really rough example in https://github.com/jku/tuf-demo github actions (but I don't want to implement this in github: I want an "actual server")
• document the "developer API" -- how are changes to metadata actually submitted to the repository: complete metadata files, just the changes, or something else?
• document how developer key management works -- meaning updates to projects keys, adding new projects (delegations), removing projects. This has all kinds of funky interactions with TUF (as keys are defined in delegating metadata)
• design multisig workflow: How are partially signed changes made available to other developers? It think this almost works by allowing "unfinished" (partially signed) new versions of metadata to exist in the live metadata repository... but this might have unintended consequences (like partially signed root files that could be downloaded by clients?)
• implement the developer API serverside
• implement developer signing tool that uses the API
• maybe implement online metadata visualization (web page per metadata file that allows browsing the metadata -- what is delegated to who)

[joshuagl]

I believe multisig are one argument in favour of the way legacy python-tuf and current go-tuf repository tools have staging directories where metadata is written to initially.

[jku]

yes, multisig discussion is going to be interesting: I think the staging concept has merit... even if I don't think the idea of just copying the whole repo to another directory and using that as base quite works (when there could be hundreds of unrelated changes going on in the same "staging"). But the developer tool and the repository being able to load specific metadata as "unfinished" with e.g. lower threshold requirements does make sense.

[joshuagl]

Another argument for staging which we should bear in mind is if a) the repository files you are editing are the live files a client interacts with or b) the repository publication is non-atomic client may run into raciness issues as described in theupdateframework/specification#223

[jku]

the only case where that can't be avoided by doing things in the correct order is, AFAICT, timestamp key rotation and that is inherently non-atomic: no amount of staging can save it from failing once in a blue moon.

What I mean is: Assuming consistent_snapshot I can add new targets versions as much (or even snapshot versions ) as much as I want: it won't affect clients in any way until the whole chain timestamp->snapshot->targets is updated

[joshuagl]

Agreed.