Repository navigation
Conversation
For use in upcoming docs on how to do offline verification with artifact attestations. Signed-off-by: Zach Steindler <[email protected]>
cliAutomation
added
the
external
|
Hi! Thanks for the pull request. Please ensure that this change is linked to an issue by mentioning an issue number in the description of the pull request. If this pull request would close the issue, please put the word 'Fixes' before the issue number somewhere in the pull request body. If this is a tiny change like fixing a typo, feel free to ignore this message. |
Signed-off-by: Zach Steindler <[email protected]>
malancas
left a comment
malancas
left a comment
There was a problem hiding this comment.
Looks good to me. The private and public flags are simply named but the included command documentation makes sense.
Signed-off-by: Zach Steindler <[email protected]>
Signed-off-by: Zach Steindler <[email protected]>
So supplying a custom trusted root works with Sigstore public good instance and GitHub's instance Signed-off-by: Zach Steindler <[email protected]>
Signed-off-by: Zach Steindler <[email protected]>
| Long: heredoc.Docf(` | ||
| ### NOTE: This feature is currently in beta, and subject to change. | ||
|
|
||
| Get a trusted_root.json file, likely for offline verification. |
There was a problem hiding this comment.
One thing that I don't think is clear with this command versus the (now removed) tuf-root-verify command is the intent. The tuf-root-verify command is about ensuring that the published tuf repository is not compromised, i.e by providing the root.json oob any client can verify this. While that is still possible with this command, I don't think it's obvious, and if if fails, would it be clear why? I think this can be solved with added documentation to this comand.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
|
Sorry for the delay on this, it's top of my backlog for tomorrow. |
|
@williammartin no worries - I might be making some slight tweaks to this pull request later today |
|
We're going to attempt to modify this pull request so that users don't have to specify |
This implementation doesn't require the user to specify if they are working with a public or private repository, and then modifies `gh attestation verify` to make an educated guess as to what trusted root to use. See #9178 for the original implementation.
|
Closing in favor of #9206 |
|
|
Nathing |
8 participants
For use in upcoming docs on how to do offline verification with artifact attestations.
When you use
gh attestation verify, it contacts GitHub services to get the keys needed to perform the verification (often called the trusted root). But if you're doing offline verification, you need to provide the trusted root manually. This subcommand makes it much easier for artifact attestation users to get the trusted root file they need for offline verification.