Implement Sigstore TUF Client Spec

[codysoyland]

Description

The TUF client in sigstore-go is very much an MVP, and we would like to enhance it to accomplish a variety of goals:

• Add the TUF Options specified in the Sigstore TUF Client specification. This includes controls for caching behavior and trusted repository mapping.
• Add support for fetching arbitrary targets, including delegate targets. Notably, this client should support the npm TUF delegation.
• Add API/ability to initialize multiple TUF repos in their own namespaces, given a URL and root.json, which can be used by private Sigstore instances with their own fully-contained TUF repos.

[codysoyland]

@kommendorkapten and I have been working on a new Sigstore TUF client internally at GitHub that accomplishes the goals stated above, and we hope to open-source it soon.

We are currently evaluating switching to https://github.com/rdimitrov/go-tuf-metadata in place of https://github.com/theupdateframework/go-tuf.

[codysoyland]

This is done in #41.

[haydentherapper]

@codysoyland To confirm, "Add API/ability to initialize multiple TUF repos in their own namespaces, given a URL and root.json, which can be used by private Sigstore instances with their own fully-contained TUF repos." is supported? Slightly separate question, is concurrent multi-TUF-repo supported?

[codysoyland]

@codysoyland To confirm, "Add API/ability to initialize multiple TUF repos in their own namespaces, given a URL and root.json, which can be used by private Sigstore instances with their own fully-contained TUF repos." is supported? Slightly separate question, is concurrent multi-TUF-repo supported?

Missed your message until now! Yes, that bullet point should be supported here. If you supply a trust anchor (TUF root.json contents) to Options.Root, you can initialize your own TUF repo.

As for multi-TUF-repo, I think the answer is no -- we're not using the multirepo package, but to be honest, I'm not sure how that works exactly.

[rdimitrov]

As for multi-TUF-repo, I think the answer is no -- we're not using the multirepo package, but to be honest, I'm not sure how that works exactly.

Hey @codysoyland and @haydentherapper 👋

So in general it aims to implement the following TAP - https://github.com/theupdateframework/taps/blob/master/tap4.md

The idea is that you set up your TUF client with a map.json file where you list all TUF repositories and the consensus you want them to have.

This allows you to configure various scenarios, some of which are:

• For example I'd like at least <this> number of <these> TUF repos to agree on <target-file-X> before I can trust/fetch it. Assuming you have 2 Sigstore TUF repos, you can create a client that fetches a trusted-root.json as long as both of the TUF repos serve the same file. If one ends up serving different file your TUF client will consider this a vulnerability and fail to fetch it.
• Another example can be having a single TUF client that fetches different target files from different TUF repositories, i.e. download all <my-vendor>-* targets from <this> TUF repo and everything else from <another>.

I don't have any information if it has been used that much yet (perhaps not), but I decided to implement it back then as it allows for some interesting configurations and use cases.

[haydentherapper]

Thanks @codysoyland and @rdimitrov. For my first question, https://github.com/sigstore/sigstore-go/blob/main/pkg/tuf/client.go#L39 confirms that we cache metadata per repo URL, so we can initialize multiple repositories given a client. This should cover the use case where I want to load in a TUF from multiple sources, eg one from the public instance, one from a private instance.

Given this, I don't think we'll need to integrate with TAP-4 yet, but I am really happy to see it implemented as a standardized solution to this problem.