Use trust config everywhere #1363
Draft
+670
−824
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
6f7b8c7 to
262043f
Compare
It looks a bit messy but I think it's fine:
|
7c2cdc5 to
f9d380e
Compare
This is not super useful at this point as the TUF repositories do not have the required signing config yet so we can't simplify the code yet: The goal is still for trustconfig to be the only source configuration like the OIDC URL. Signed-off-by: Jussi Kukkonen <[email protected]>
We have previously done this for TrustedRoot but doing this for the whole TrustConfig makes sense. The only complication is that production instance does not have the SigningConfig component yet so we need to provide a fallback for that. Signed-off-by: Jussi Kukkonen <[email protected]>
This change makes almost all code paths now use TrustConfig to choose the sigstore instance (urls, keys, validity periods, etc). * OIDC url now comes from signingconfig too * Some production()/staging() methods remain because they're used by tests or special cases like "fix-bundle" * Likewise some hard coded urls are left in the code since they are used by some special case Signed-off-by: Jussi Kukkonen <[email protected]>
Probably makes sense to handle this in ClientTrustConfig only: less code that way. The tests will start passing once staging TUF contains signingconfig (and we have updated our test copies of staging TUF) Signed-off-by: Jussi Kukkonen <[email protected]>
Commit is large just because the test and embedded assets for staging are updated. * Update the embedded data in sigstore/_store * Also update the test assets in test/assets * refactor the embedded asset lookup: use the URL to build the asset dir. This means less code duplication and easier to make this work with non-Public Good Instance TUF repos * Make the tuf module work with non-PGI instances: if the local TUF metadata is initialized out of band, tuf module just works with it. If a root.json is provided in _store, it is still always used to initialize the client Of special note is "signing_config.v0.2.json" for production: This does not actually exist yet in the TUF repository but I've added one in sigstore/_store and use it as a workaround in ClientTrustConfig.from_tuf() -- this way the code can otherwise remain identical for both staging and prod. Signed-off-by: Jussi Kukkonen <[email protected]>
Default now comes from the trust config. The option is also not especially in conflict with staging. Signed-off-by: Jussi Kukkonen <[email protected]>
Signed-off-by: Jussi Kukkonen <[email protected]>
They will be if there are any rekor 2 instances, but currently TSA is not strictly needed. Signed-off-by: Jussi Kukkonen <[email protected]>
This is not a really a user visible change so I'm debating if the item is even needed. Signed-off-by: Jussi Kukkonen <[email protected]>
This is not a very useful helper: just use the url at callsite Signed-off-by: Jussi Kukkonen <[email protected]>
|
ah, I forgot that if I update the staging test assets I need to handle the TUF timestamp expiring... I think that's just a minor monkeypatch (or at worst I need to generate a new tuf repo) but it does mean this is not yet ready for review |
dcf6234 to
0abec00
Compare
The current staging TUF assets expire in 3 days: mock datetime.now() so they seem valid in the tests. This is absolutely quite sketchy but seems to work. Signed-off-by: Jussi Kukkonen <[email protected]>
0abec00 to
a71f387
Compare
|
sigh, now the tests are failing because timestamp-authority is doing a release and our tests are expecting it to be available already because the tags are there... I will continue on monday |
27 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Use TrustConfig throughout the project
This looks complete to me now. I'm keeping it a draft while
Apologies for the seemingly large PR. It's mostly just the assets getting updated: this asset update is not strictly necessary but it is done to get test coverage for signingconfig handling (since new root-signing-staging has a signingconfig 0.2).
Fixes #1347, fixes #1347, fixes #1371
TrustConfig.signing_configto get the OIDC urlfrom_tuf()method for TrustConfig and not Trustedroot