Introduce v0.2 TrustedRoot, un-deprecate log ID #690
Merged
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
haydentherapper
requested review from
loosebazooka,
woodruffw and
kommendorkapten
haydentherapper
commented
Jul 7, 2025
| @@ -67,50 +67,50 @@ class Signature(betterproto.Message): | |||
|
|
|||
|
|
|||
| @dataclass(eq=False, repr=False) | |||
| class DsseRequestV002(betterproto.Message): | |||
There was a problem hiding this comment.
@woodruffw any guesses as to why my build output differs from CI? I can just omit this file, I’ve seen this before though.
There was a problem hiding this comment.
For now, I've reverted this change. Will dig in more later.
There was a problem hiding this comment.
Yeah, no idea unfortunately. My best guess is that something in your local resolution is diverging from the CI's resolution, producing different codegen, but I have no idea what would cause that 😞
kommendorkapten
previously approved these changes
Jul 7, 2025
As we learned when we introduced a new SigningConfig version, adding fields to the proto isn't a breaking change, but setting these fields in JSON and unmarshalling the object is a breaking change. Since we've added operator and checkpoint_key_id to the Instance message, this requires introduced a new TrustedRoot version, which I've done in this PR as v0.2. As with SigningConfig, I've made it optional for clients to indefinitely support old versions, but it should be little work for a client to support both versions concurrently. I've also un-deprecated log ID. This was premature since no clients supported checkpoint key ID yet. With Rekor v2, we'll be setting the same value in both log_id and checkpoint_key_id, so clients can continue to ignore checkpoint_key_id for now. Signed-off-by: Hayden B <[email protected]>
haydentherapper
force-pushed
the
undeprecate
branch
from
f44a457 to
559aa06
Compare
kommendorkapten
approved these changes
Jul 8, 2025
woodruffw
approved these changes
Jul 9, 2025
|
Do y'all have opinions on if I should cut a new minor release vs a patch release? Given this is a new TrustedRoot release, I'm leaning towards a new minor 0.5 |
|
A new minor seems like the correct choice 👍 |
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.
As we learned when we introduced a new SigningConfig version, adding fields to the proto isn't a breaking change, but setting these fields in JSON and unmarshalling the object is a breaking change. Since we've added operator and checkpoint_key_id to the Instance message, this requires introduced a new TrustedRoot version, which I've done in this PR as v0.2. As with SigningConfig, I've made it optional for clients to indefinitely support old versions, but it should be little work for a client to support both versions concurrently.
I've also un-deprecated log ID. This was premature since no clients supported checkpoint key ID yet. With Rekor v2, we'll be setting the same value in both log_id and checkpoint_key_id, so clients can continue to ignore checkpoint_key_id for now.
Summary
Release Note
Documentation