Print message when verifying with old TUF targets #1468
Merged
Conversation
This file contains 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
Typical verification used VerifyBundle, which called GetRekorKeys, which fetches keys from the TUF repo. If the bundle was not present or for a specific error when a duplicate log entry was present, then the tlog entry would be verified using a public key fetched from Rekor's API. This key was not verified using TUF metadata. This change simply removes the API call and uses Rekor public keys from the TUF repo. Tested locally by not including the Rekor bundle in the OCI signature, which will hit the code path to fetch the entry from the log. Signed-off-by: Hayden Blauzvern <hblauzvern@google.com>
This adds console messages when the TUF metadata used for Rekor or the CTFE key is marked as expired. I haven't added a log message for Fulcio yet. The way that certificates are verified is different. Instead of multiple verifications where we can easily determine which key successfully verified an object, the x509 library uses a CertPool and returns a valid chain. I'll need to plumb through the TUF information. Signed-off-by: Hayden Blauzvern <hblauzvern@google.com>
|
The UX here is fine, is there any way we could make this work for machine readable output too? Maybe include the TUF root we verified against? |
|
I'll take a look at piping some information to stdout. Is there any existing format for machine readable output? Just print JSON? |
This can come in a separate PR - but yeah it's typically just when we do --format=json. The basic idea is just that if we feel information is important enough to display to a person, it probably makes sense to make it parseable in a script too. |
asraa
approved these changes
Feb 16, 2022
hatmarch
pushed a commit
to hatmarch/cosign
that referenced
this pull request
Apr 19, 2022
* Verify tlog entries using the Rekor public keys from TUF Typical verification used VerifyBundle, which called GetRekorKeys, which fetches keys from the TUF repo. If the bundle was not present or for a specific error when a duplicate log entry was present, then the tlog entry would be verified using a public key fetched from Rekor's API. This key was not verified using TUF metadata. This change simply removes the API call and uses Rekor public keys from the TUF repo. Tested locally by not including the Rekor bundle in the OCI signature, which will hit the code path to fetch the entry from the log. Signed-off-by: Hayden Blauzvern <hblauzvern@google.com> * Print message when verifying with old TUF targets This adds console messages when the TUF metadata used for Rekor or the CTFE key is marked as expired. I haven't added a log message for Fulcio yet. The way that certificates are verified is different. Instead of multiple verifications where we can easily determine which key successfully verified an object, the x509 library uses a CertPool and returns a valid chain. I'll need to plumb through the TUF information. Signed-off-by: Hayden Blauzvern <hblauzvern@google.com>
mlieberman85
pushed a commit
to mlieberman85/cosign
that referenced
this pull request
May 6, 2022
* Verify tlog entries using the Rekor public keys from TUF Typical verification used VerifyBundle, which called GetRekorKeys, which fetches keys from the TUF repo. If the bundle was not present or for a specific error when a duplicate log entry was present, then the tlog entry would be verified using a public key fetched from Rekor's API. This key was not verified using TUF metadata. This change simply removes the API call and uses Rekor public keys from the TUF repo. Tested locally by not including the Rekor bundle in the OCI signature, which will hit the code path to fetch the entry from the log. Signed-off-by: Hayden Blauzvern <hblauzvern@google.com> * Print message when verifying with old TUF targets This adds console messages when the TUF metadata used for Rekor or the CTFE key is marked as expired. I haven't added a log message for Fulcio yet. The way that certificates are verified is different. Instead of multiple verifications where we can easily determine which key successfully verified an object, the x509 library uses a CertPool and returns a valid chain. I'll need to plumb through the TUF information. Signed-off-by: Hayden Blauzvern <hblauzvern@google.com>
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.
Summary
This adds console messages when the TUF metadata
used for Rekor or the CTFE key is marked as expired.
I haven't added a log message for Fulcio yet. The way
that certificates are verified is different. Instead of
multiple verifications where we can easily determine
which key successfully verified an object, the x509
library uses a CertPool and returns a valid chain.
I'll need to plumb through the TUF information.
Ticket Link
Fixes
Release Note