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

Add sigstore root-signing as static test data #264

Merged
merged 1 commit into from
Feb 17, 2025

Conversation

jku
Copy link
Member

@jku jku commented Feb 9, 2025

Add sigstore root-signing repository as static test data

This is now possible since static repos can define a reference time that client-unders-test should use

@jku jku force-pushed the code-cleanup branch 2 times, most recently from fdbb9f5 to ead2896 Compare February 9, 2025 10:33
@jku jku changed the title Code cleanup Add sigstore root-signing as static test data Feb 9, 2025
@jku jku force-pushed the code-cleanup branch 5 times, most recently from 36b2fd1 to 26205f0 Compare February 11, 2025 10:12
This is a fast expiring repository so will requires the faketime support

Signed-off-by: Jussi Kukkonen <jkukkonen@google.com>
@jku jku marked this pull request as ready for review February 11, 2025 16:52
@loosebazooka
Copy link
Collaborator

Could this also live in sigstore-conformance? Or do we expect tuf clients to be consuming sigstore metadata outside of the sigstore-clients? Or is the sigstore tuf root a good example of real world tuf use?

Can we include a readme on how to keep this up to date? (should it be kept regularly up to date? Does it have an effect on breaking clients?)

@jku
Copy link
Member Author

jku commented Feb 12, 2025

Could this also live in sigstore-conformance? Or do we expect tuf clients to be consuming sigstore metadata outside of the sigstore-clients? Or is the sigstore tuf root a good example of real world tuf use?

I don't think sigstore-conformance needs something like this -- passing that test suite already implicitly requires being able to handle the live root-signing repo at that moment. I don't expect non-sigstore clients to consume root-signing (except for purposes like this test suite).

I added this here for two reasons:

  • I think the repository is a decent compliance test: if your client is spec-compliant it should be able to operate with root-signing
  • Even if it turns out there's something a bit wrong with the metadata, it's still a sample of a real world repository: A useful test even if clients then decide to xfail it

Can we include a readme on how to keep this up to date? (should it be kept regularly up to date? Does it have an effect on breaking clients?)

I didn't include a "version number" in the directory name like I did for the tuf-on-ci demo content but the way I was thinking about it was the same: updating is likely not ideal as this is the state of the repository at a specific time. We don't want to stop testing that specific state even if we later add another state of the same repository. We can add complete new repositories later (like sigstore-root-signing-2026) if there are changes that seem meaningful to test. I don't know if regularly updating is that useful... time will tell

@jku jku merged commit f0ae391 into theupdateframework:main Feb 17, 2025
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants