Add SIP for signing Spin releases #1217
Conversation
| ├── artifact.sig | ||
| └── crt.pem | ||
|
|
||
| $ cosign verify-blob \ |
There was a problem hiding this comment.
Cosign appears to have built-in support for github oidc now via --certificate-github-workflow-* flags. (which I haven't actually tested...)
There was a problem hiding this comment.
--certificate-github-workflow-sha appears to be part of the signature, not sure about others, haven't been able to validate them.
|
cc @vdice since you are the most familiar with the release process. |
| ``` | ||
|
|
||
| - when uploading the assets to the new release, the certificate and signatures | ||
| need to be added side-by-side with the actual artifact |
There was a problem hiding this comment.
Should we clarify the expected interpretation of 'side-by-side'? I'm assuming this should be interpreted as: include the .sig and .pem files in the same archive containing the artifact and related files (eg LICENSE, README, etc.)?
There was a problem hiding this comment.
It depends on what we want to sign — the archive containing everything, or just the binary.
Since we already compute the content digest of the archive, it might make sense to sign that. If we sign the archive, then the signature and certificate would be distributed as separate release artifacts.
If we only sign the binary, then we could distribute the signature and certificate inside the archive.
| - when uploading the assets to the new release, the certificate and signatures | ||
| need to be added side-by-side with the actual artifact | ||
|
|
||
| - instructions are added for users on how to use `cosign` to verify the |
There was a problem hiding this comment.
Tangential idea: I wonder if a badge service might be neat here. A GET req to the badge service would trigger an agent to download assets, perform the verification and return status. Badge could go on the Spin README, etc.
| Error: verifying blob [fake-artifact]: searching log query: [POST /api/v1/log/entries/retrieve][400] searchLogQueryBadRequest &{Code:400 Message:unmarshalling entry: verifying signature: invalid signature when validating ASN.1 encoded signature} | ||
| ``` | ||
|
|
||
| Attempting to verify a signature using a different identity also results in an error: |
There was a problem hiding this comment.
For completeness, do we want to illustrate the scenario when one or both of the .sig and .pem files are fake/incorrect (but artifact, cert-identifier and cert-oidc-issuer correct)?
| ``` | ||
|
|
||
| After the action is executed, the new artifact is released and its signature | ||
| published using Sigstore. To validate the signature, a user will then need to |
There was a problem hiding this comment.
Implementation detail I suppose, but it seems like here down to the rest of the doc should be available to users via documentation as well.
There was a problem hiding this comment.
Yes, a lot of this requires instructions for how users would interact and perform checks on the signatures.
| echo 'hello world' > out/artifact | ||
|
|
||
| - name: Sign the artifact with GitHub OIDC token | ||
| run: cosign sign-blob --output-certificate out/crt.pem --output-signature out/artifact.sig out/artifact --yes |
There was a problem hiding this comment.
Thinking ahead to our use in Spin and how we produce a number of <os>-<arch> builds. Is the crt.pem expected to be different for each artifact? I take it both artifact.sig and artifact itself, naturally, would be.
There was a problem hiding this comment.
Yes, each <os>-<arch> build (whether that is directly the Spin binary or the archive containing the readme and license) would have a signature and certificate associated.
| ```bash | ||
| $ cosign verify-blob \ | ||
| --signature artifact.sig --certificate crt.pem \ | ||
| --certificate-identity https://github.com/fermyon/spin/.github/workflows/release-sign.yml@refs/heads/main \ |
There was a problem hiding this comment.
Brainstorming how to present the correct value here for users, eg refs/heads/main for main (or refs/tags/canary for the corresponding canary release) and refs/tags/<tag> for other vX.X.X tagged releases.
Maybe the automation agent (GH action) attaches a verification-notes.txt asset or some such to a given release with command samples and notes, etc, filled-in with the proper strings. Or perhaps a default section added to the release notes by the author...
There was a problem hiding this comment.
The documentation and release notes would contain optional instructions on getting the certificate and signature, and the command required to perform the signature validation.
| bound to an OIDC identity, published to Rekor | ||
| - Rekor — transparency and timestamp service, provides a ledger that can be | ||
| audited | ||
| - `cosign sign` — the CLI that connects an OIDC identity to Fulcio to generate the |
There was a problem hiding this comment.
Trying to get an idea of the external services involved when invoking this command... Fulcio? Others?
Perhaps a rare event but what is our approach when we're unable to sign due to external service issues?
There was a problem hiding this comment.
Fulcio and Rekor are both public good services that this mechanism uses while performing a signature, and that users would invoke while checking signatures.
If either is down, our signature process will fail.
Given that fairly large projects such as Kubernetes have already adopted this process, and that this has been marked as stable, my assumption is that the services should be relatively stable.
While we should sign canary builds, it's only stable releases that we are asking users to trust. Given that, rare events when we would be unable to sign stable releases should be indeed rare.
(if our experience is different as we test this, happy to re-evaluate this)
| to verify the integrity of the package they downloaded. The signature should | ||
| offer two guarantees: the author of the artifact is indeed the one expected by | ||
| the consumer, and the content of the artifact has not been tampered with since | ||
| its creation. |
There was a problem hiding this comment.
I don't have any comment on the technology, which I realise is the focus of the SIP, but I'd find it really useful to understand what guarantees it provides, what attacks it mitigates, what malicious actions it allows a consumer to detect. The proposal mentions "validate the integrity" but clearly means something more than file integrity (which is presumably guaranteed with the digest). Is it about the attack of someone posting a false file somewhere and claiming it to be Spin?
There was a problem hiding this comment.
Besides the file integrity (which is now verifiable using a transparency log, rather than just using a file), a user can validate that the build was actually generated by the fermyon/spin repo, through a GitHub action workflow they can inspect at a given SHA or tag, and that us or someone else has not replaced the binary since the GitHub infrastructure built it at the time of the SHA or tag.
Besides this guarantee, this can be later expanded to include even more attestations (such as SLSA, which could include even more provenance data).
| ├── artifact.sig | ||
| └── crt.pem | ||
|
|
||
| $ cosign verify-blob \ |
There was a problem hiding this comment.
For me, it would be super useful to have the user experience of this clearly called out - the "GitHub actions example" is not a natural place to look for it grin
There was a problem hiding this comment.
Users should have this in a documentation section on the developer website.
For the SIP, I renamed the section.
| --certificate-oidc-issuer https://token.actions.githubusercontent.com \ | ||
| artifact | ||
|
|
||
| Verified OK |
There was a problem hiding this comment.
would be nice to have a spin self update command or plugin that handles this verification part for the user if possible in the future.
|
|
||
| The goal of this SIP is to define the tools used for generating signatures for | ||
| the Spin project, and to provide a standard process for signing release artifacts | ||
| for Spin and related projects. |
There was a problem hiding this comment.
Should we consider changing the way we expect plugins to be signed as well? SHA checksums seem sufficient for plugins because they are verifying that the remote executable/source code is what is defined in the manifest (matches the SHA). The difference here is that the manifest SHA is used to verify the plugin rather than the user. This seems worth evaluating with regards to the note on "related projects"
Signed-off-by: Radu Matei <[email protected]>
radu-matei
force-pushed
the
sip012-signing-spin-releases
branch
from
1e1a07d
to
510e621
Compare
Rendered SIP