Milestone 1: minimal TUF

[jku]

• included is a client that has matching functionality vs baseline
• repository metadata has been published
• some (repository) design notes have been written

[jku]

A few possible changes still:

• I'm considering making keyids readable names -- it's not strictly spec compliant but it would make this much easier to understand and talk about
• Also considering removal of index.json files: The repository design allows just looking at targetpaths to gather all of this info, it's just that ngclient doesn't currently expose the list of targetpaths (RFE: expose delegated metadata to client application theupdateframework/python-tuf#1995) so this would have to access ngclient internals. The benefit would be a more straightforward implementation that is easier to understand

Both of these could be future enhancements waiting for library improvements as well

[MVrachev]

Do you want us to make a high-level review on this @jku or do you want us to wait until you mark it as a non-draft pr?

[jku]

Either way works... I've been moving files around but I think it looks ok now.

I think I'll have a final look by tomorrow, and list some follow-up work and then mark if ready. But I don't mind getting comments now.

[jku]

Also considering removal of index.json files

I will try this (by using some ngclient internal interfaces), and see how it works... I will keep this a draft until I see how that works and decide if I implement it in this PR or not

EDIT: this is not any less code but I think it's definitely the right path:

• it removes one get_targetinfo() and one download_target() call from a normal artifact download, this is totally worth doing
• repository no longer needs index.json to be kept in sync with the repository content

[jku]

• I modified the design so index.json is no longer there: this makes both the download process and the repository content simpler
• I don't think there's anything critical missing from calling this milestone 1:
  • saving artifacts outside of git only makes sense when we have the upload functionality (otherwise it's too much manual work)
  • the way data is encoded in the targetpath could probably be improved... but if there's some really useful invention later, we can always come back to this milestone and improve it (in a branch if needed)
  • the fact that this uses python-tuf internals (to find all the targetpaths) is unfortunate but I think a good way to test the idea for RFE: expose delegated metadata to client application theupdateframework/python-tuf#1995: again, we can always fix this later if python-tuf gets the API (or if we decide that was a dumb idea)

I think this is ready. That said, I welcome opinions on high level decisions as well as the details.

[jku]

It would probably be good if the main README documented the current state or milestone at a high level: so people who come to the project for the first time could see both what the state is and what the goal is...

[jku]

Also, something we could already have at milestone 1: hashed bin delegations. This would give a notion of scalability to this setup.

However, I think I'll rather wait for

• succinct delegations to arrive in a python-tuf release
• a bit of repository helper code to arrive in tools (like repository-editor-for-tuf): I'd like a single command to add a file to a repository (so that it actually gets added to the correct targets file). This doesn't currently exist

[joshuagl]

Given that we're specifically focused on modelling community content repositories, which tend to be large, including hashed bin delegation early is a good idea.

[lukpueh]

This is great! I haven't looked at playground_client.py in detail yet, but I very much like the overall direction here. Two questions:

What is the plan for playground/client over the course of the roadmap? Now that it has an initial root and a client that supports a minimal TUF repository, I think it should be useable for any repo design of future milestones, bar some minor configuration such as remote BASE_URL, and local METADATA_DIR to avoid conflicts. Most changes of functionality in playground/client (e.g. adopt theupdateframework/python-tuf#1995) should be doable in a backwards-compatible way so that it works with all repo designs starting at 01-TUF-MINIMAL.md. I ask this because we briefly talked about a different branch for each milestone, or a single branch with different client directories. But if my assumption above is correct, we won't need that and will instead have a growing design-milestones/ dir and an evolving TUF-ROADMAP.md doc which always captures all accomplished milestones. Also, if this is correct, we could make the playground/client/README.md more generic. Of course we can make these decisions as we move along the ROADMAP. If, for instance, we need a custom network implementation for a future client, it could become messy.

The other question concerns the current set of private keys used to sign the metadata. IIUC, these are on your local machine, @jku? Should we share them among administrators on this repo so that they can update any metadata? At least the root key?

[jku]

1. client roadmap

What is the plan for playground/client over the course of the roadmap? Now that it has an initial root and a client that supports a minimal TUF repository, I think it should be useable for any repo design of future milestones...

I fear devil is in the details though: e.g. the current target listing hack depends on knowing the specific targets metadata name. This will break the moment we have any delegations. Likewise I would not be surprised if some unseen requirement means we actually need index.json-like files in the future anyway. So changes are likely to happen even if the core client likely looks roughly the same. Still, no need to create branches until we realize something really should have been in milestone X but wasn't there.

2. keys

Many ways to handle this -- you could just make a PR to the playground-tuf-minimal repository that adds your root key and developer key, and I could sign that change... I can give pointers on easiest ways to do this if this sounds good.

3. succinct delegations

This now works in repository-editor-for-tuf (using unreleased python-tuf) so I want to add a succinct delegation here but I think not in this milestone: it requires solving the target listing issue mentioned above

[jku]

I think I will merge this now: let's handle remaining complaints in new issues