-
Notifications
You must be signed in to change notification settings - Fork 91
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
Surfacing Verification #370
Conversation
Signed-off-by: hayleycd <[email protected]>
✅ Deploy Preview for docssigstore ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Signed-off-by: hayleycd <[email protected]>
Signed-off-by: hayleycd <[email protected]>
Signed-off-by: hayleycd <[email protected]>
|
||
Verfication requires the user of your software to have prior knowledge of the identity of the signer. To help users successfully verify your project we recommend that you publish the signature information in an easily discoverable place that can only be updated by trusted people. For example, the Python Software Foundation [publishes](https://www.python.org/downloads/metadata/sigstore/) a table that includes each signed CPython release, the release manager's email address, and the associated OIDC issuer. | ||
|
||
Your project README is an excellent place to let your users know that your project is signed with Sigstore and include a link to further signature information. |
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.
These recommendations sounds great!
I'm not sure if this would be too in the weeds, but in the event of a compromise of the repository and assuming the binary is released from GitHub, both the binary and the identity information would be compromised. Do you think it'd be worth stating the threat model here?
Eventually, we can further reduce risk with other solutions - identity policies shipped by registries, or using transparency logs to commit to identity mappings.
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.
If we name that threat model here then I think it would be confusing if we don't also offer an easy solution to that in the same place, which we don't really have.
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 think I agree with colleen that the threat model and the upcoming solutions can be added at once, once those solutions are in place. But I'm willing to add it in if either of you would like me to.
Co-authored-by: Hayden B <[email protected]> Signed-off-by: Hayley Denbraver <[email protected]>
Co-authored-by: Hayden B <[email protected]> Signed-off-by: Hayley Denbraver <[email protected]>
Signed-off-by: hayleycd <[email protected]>
|
||
Verfication requires the user of your software to have prior knowledge of the identity of the signer. To help users successfully verify your project we recommend that you publish the signature information in an easily discoverable place that can only be updated by trusted people. For example, the Python Software Foundation [publishes](https://www.python.org/downloads/metadata/sigstore/) a table that includes each signed CPython release, the release manager's email address, and the associated OIDC issuer. | ||
|
||
Your project README is an excellent place to let your users know that your project is signed with Sigstore and include a link to further signature information. |
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.
If we name that threat model here then I think it would be confusing if we don't also offer an easy solution to that in the same place, which we don't really have.
@@ -173,7 +175,7 @@ invalid or missing annotation in claim: map[sig:original] | |||
|
|||
Each signature is printed to `stdout` in a JSON format: | |||
|
|||
``` | |||
```shell | |||
$ cosign download signature us-central1-docker.pkg.dev/user-vmtest2/test/taskrun |
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.
If you're removing the prompt symbol from all the examples do this one too?
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.
It's a linter thing. It wanted me to remove the "$" when it was only a command, but not when the result was included. I'm happy to change it if you want me to, but there was a reason I left it in.
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.
Got it, thanks for explaining
Signed-off-by: hayleycd <[email protected]>
Signed-off-by: hayleycd <[email protected]>
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.
LGTM! Any other comments Colleen?
@@ -173,7 +175,7 @@ invalid or missing annotation in claim: map[sig:original] | |||
|
|||
Each signature is printed to `stdout` in a JSON format: | |||
|
|||
``` | |||
```shell | |||
$ cosign download signature us-central1-docker.pkg.dev/user-vmtest2/test/taskrun |
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.
Got it, thanks for explaining
Summary
Addresses #369
Adds a few sections to stress the importance of verification and to make it easier to do.