-
Notifications
You must be signed in to change notification settings - Fork 379
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
Merge release-5.32 into main #2532
Conversation
We are on the 5.32 branch and the previous release was 5.32.1. Signed-off-by: Miloslav Trmač <[email protected]>
[release-5.32] Fix the version number
Signed-off-by: Miloslav Trmač <[email protected]>
Use a struct as an input, so that the parameters are named and we minimize risk of inconsistencies, and make it easier to add more sources. Should not change behavior. Signed-off-by: Miloslav Trmač <[email protected]>
Extend loadBytesFromConfigSources to return multiple values, and to support reading the from files; then share the code. Signed-off-by: Miloslav Trmač <[email protected]>
because we will want to support multiple public keys, and that's easier to do in a separate function. Should not change behavior except for order of error checks. Signed-off-by: Miloslav Trmač <[email protected]>
The new fields `KeyPaths` and `KeyDatas` is taken directly from `/etc/containers/policy.json` and allows users to provide multiple signature keys to be used to verify images. Only one of the keys has to verify, thereby this mechanism allows us to have support seamless key rotation on a registry. This fixes containers#2319 Signed-off-by: Dan Čermák <[email protected]> Co-authored-by: Danish Prakash <[email protected]> Signed-off-by: Miloslav Trmač <[email protected]>
Add rekorPublicKeyPaths and rekorPublicKeyDatas , similar to the primary root of trust public keys. Signed-off-by: Miloslav Trmač <[email protected]>
This adds the ability to accept sigstore signatures signed by any key from a set of several (huge thanks to @dcermak and @danishprakash for doing almost all the work), and Rekor log presence proofs signed by any key from a set of several keys. Signed-off-by: Miloslav Trmač <[email protected]>
Signed-off-by: Miloslav Trmač <[email protected]>
Release 5.32.2
version/version.go
Outdated
@@ -6,7 +6,7 @@ const ( | |||
// VersionMajor is for an API incompatible changes | |||
VersionMajor = 5 | |||
// VersionMinor is for functionality in a backwards-compatible manner | |||
VersionMinor = 33 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we want this. Should main be at 5.33.*-dev?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The net effect of this PR should be to keep main at 5.33.0-dev , as in https://github.com/mtrmac/image/blob/into-main/version/version.go (and the PR’s file change view is showing no changes).
The PR contents are all contents of the release-5.32
branch, + a merge commit into main
(it needs to be that way, the goal is to make the commit tagged 5.32.2 an ancestor of the main
branch).
So, we do include the 5.32 version bumps as individual commits, but the merge commit undoes the version.go
changes.
Do you want the commits that changed the versions too? The other commits look fine to me, but it looks like you need to update this. |
We need the
Rebased. |
LGTM |
/approve |
… so that Go considers commits on
main
later than the just-released 5.32.2 version.