Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable easier embedded root version updates for client codebases #817

Open
jku opened this issue May 3, 2023 · 2 comments
Open

Enable easier embedded root version updates for client codebases #817

jku opened this issue May 3, 2023 · 2 comments
Labels
enhancement New feature or request

Comments

@jku
Copy link
Member

jku commented May 3, 2023

Description

Clients embed a version of root metadata as the initial source of trust into their client apps and typically into their source code repos. They should also update that version sometimes, and it seems this is not always happening (see sigstore/sigstore#1138)

The benefits of updating the embedded root are:

  • less network traffic when clients avoid downloading old root metadata
  • better client user experience (because less downloads)
  • slightly better security as well

There is a downside too:

  • updating the root metadata should not be done lightly or in an automated fashion as it is the source of all trust

Possible ideas to fix

To make updates easy and to minimize the mentioned downside, sigstore root-signing could probably make things easier for client projects. Some potential ideas:

  • maybe include a "suggestion to update embedded root" in some communications to client developers when root is updated, with advice on how to safely update their embedded root
  • maybe create a reusable GH workflow that files an issue in the client github repo if the embedded root is not up-to-date ( see https://github.com/theupdateframework/specification/blob/master/.github/workflows/check-latest-spec-version.yml for an example of a similar workflow in the TUF spec repository -- this workflow is used in the TUF implementation repositories). This issue could document what should be updated and how the root should be verified to be correct.

cc @joshuagl

@jku jku added the enhancement New feature or request label May 3, 2023
@joshuagl
Copy link
Member

joshuagl commented May 3, 2023

I like the idea of having an action client implementers can choose to use. I think we should do that and make noise in the Sigstore client meeting so that folks are aware.

We should create a short Markdown doc in the repo here that the issue and the meeting can link to in order to understand why updating trusted root metadata to newer versions is useful as well as how to do the update securely.

@jku
Copy link
Member Author

jku commented May 4, 2023

... create a reusable GH workflow that files an issue in the client github repo if the embedded root is not up-to-date

Thinking this through: We probably don't want to file the issue immediately when root-signing git changes: instead the trigger should be the published metadata changing (and even then preferably a couple of weeks after that time). So the workflow process would be

  • periodically run a TUF client to get up-to-date local metadata cache from sigstore repository (this could be done with the sigstore client itself but a tiny TUF app included in the workflow might be easiest)
  • compare the fresh cached root to the clients embedded root (embedded root path is a workflow input)
  • file an issue if the files do not match (could make a PR as well but I'm not sure if that's too much automation?)

TODO: what do we suggest as the easiest way for client maintainers to fetch and store the new root? Running their own client and using the root file from their own local cache?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants