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
sign binaries with sigstore #120
Comments
possible dupe of #21 |
(making this a more specific task) |
Registering interest in this implementation as we're going to add support for checking sigstore in binstall in the near-but-not-defined future, so would be annoying if we were incompatible by accident |
With #243 done this is the next logical step for integrity/checksum/signing stuff but i'm definitely in "i have no idea what i'm doing" territory with sigstore |
Although no releases yet, we started testing with We definitely want to rework our workflow to align with what y'all decide to do as we'd like less moving parts (and not modifying generated workflows, although was just a hack for PoC). Happy to provide feedback too, and thanks for an awesome tool! :) Our frankenflow: https://github.com/lndk-org/lndk/blob/5f0ed07eb3b669d6dec3edb1813b50f18e78bc6e/.github/workflows/release.yml#L134 |
FTR The design we're thinking of with binstall is to use the cosign (sign-blob and) verify-blob workflows (but in Rust, not through the CLI go tools) directly on the packages / archives / distributed artifacts, not on generated checksum files, as cosign already does the hashing internally and because that lets us verify from the files we're already downloading, rather than having to fetch an extra one. But awaiting more advice / consensus / free time before implementing :) |
Yeah that would be ideal. It's just that I was tied to wanting a single bundle, hence the single checksums, but honestly I don't see the point of that anyway as users generally want one blob so having one bundle per blob is fine 😅 But I did see some issue that they were considering having all the signatures in a single co-sign bundle which would be a nice optional feature. |
I don't have a ton of extra time, but I'm going to try integrating this on my fork via |
Going to note that github has released this https://github.blog/2024-05-02-introducing-artifact-attestations-now-in-public-beta/ which might simplify the story at least for github-actions. |
he, literally published yesterday! Thanks, this might be what we want so I'll look into it as well. |
hey folks! we would be super excited to have this upstreamed. to the extent that we'd be willing to pay/sponsor someone to do it. we don't have a ton, but this integration would be very useful. feel free to hop on the discord if that's of interest to you and we can chat about it! |
So getting GitHub Attestations integrated with cargo-dist is super easy. It can literally be a bool config and I've managed to do that successfully in an afternoon as it basically just modifies the release.yaml. I've also done a bit of work integrating with the sigstore-rs stuff and it doesn't seem too complicated (just more moving parts, but allows more flexibility). I think it would be great to have both. GitHub Attestations is an easy and quick win, though! I'll join the Discord to chat more :) |
As a developer I would like to have the ability to sign the binaries I release.
This could be done using sigstore as they provide a fantastic keyless signing ecosystem (can use GitHub OIDC), as well as rust bindings sigstore-rs.
The text was updated successfully, but these errors were encountered: