review: doc: add SUPPLY-CHAIN.md #6063
Conversation
SUPPLY-CHAIN.md
Outdated
| Get the sigstore/rekor attestation: | ||
| [https://search.sigstore.dev/?hash=804c2ab449cc16052b467edc3ab1f7cf931f8e679685c0e16fab2fcc16ecfb41](https://search.sigstore.dev/?hash=804c2ab449cc16052b467edc3ab1f7cf931f8e679685c0e16fab2fcc16ecfb41) | ||
|
|
||
| Manually verifying using openssl: Sigstore docs provide a [tutorial](https://docs.sigstore.dev/logging/verify-release/) |
There was a problem hiding this comment.
It is unclear where do I get .pem and .sig file for spoon artifact in order to verify using openssl. Could you list the steps for that here?
There was a problem hiding this comment.
I tried replicating this part of the tutorial for some spoon artifacts, but the data structure differs from their examples.. I am unsure if this is because the tutorial is outdated or because of the attest-build-provenance action's usage of signatures.
On further thought, I think that the entry in sigstore/rekor might be a signature of the actual attestation rather than the artifact, that would also explain why the hashes differ as you mention in the previous comment.
My suggestion is that I remove the manual part and only provide examples of how to verify attestations using GitHub CLI, adding how to do it with a locally dowloaded attestation from the spoon repo.
There was a problem hiding this comment.
On further thought, I think that the entry in sigstore/rekor might be a signature of the actual attestation rather than the artifact
entry is just the UUID so it simply a unique random number so it cannot be a signature.
I remove the manual part and only provide examples of how to verify attestations using GitHub CLI,
I am okay with it. :)
There was a problem hiding this comment.
Updated the guide! :)
|
@I-Al-Istannen @monperrus ready for merge from my side |
ludvigch
changed the title
This PR adds documentation of the changes in #6016 as well as a short description on how to verify the attestations created during a release. I am a bit unsure if the manual verification process is relevant or if it suffices with the simpler method of using GitHub CLI to verify an attestation?
Addressing @monperrus suggestion