cargo-dist icon indicating copy to clipboard operation
cargo-dist copied to clipboard

sign binaries with sigstore

Open rgreinho opened this issue 2 years ago • 13 comments

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.

rgreinho avatar Feb 12 '23 19:02 rgreinho

possible dupe of #21

Gankra avatar Feb 16 '23 19:02 Gankra

(making this a more specific task)

Gankra avatar Feb 16 '23 20:02 Gankra

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

passcod avatar Mar 17 '23 09:03 passcod

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

Gankra avatar May 10 '23 15:05 Gankra

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 cargo-dist before #243 went in. Unfortunately ended up modifying the generated workflow which I guess defeats the purpose of a feature of cargo-dist, but we ended up with something working with the cosign GH Action. We decided generating one checksum file and signing that was easier for us. Although not with GitHub OIDC as that's not available for plain blobs with cosign yet, just container images. So we had to generate a keypair using the approach here.

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

dunxen avatar May 13 '23 07:05 dunxen

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 :)

passcod avatar May 13 '23 12:05 passcod

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.

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.

dunxen avatar May 13 '23 12:05 dunxen

I don't have a ton of extra time, but I'm going to try integrating this on my fork via sigstore-rs at least for our workflow of managing the cosign key ourselves to sign the blobs and push the sig to the registry (i.e. no keyless blob signing). I'll comment my findings (if they're interesting). At some point (if someone doesn't have something nicer) I'd be happy to try go through the process of upstreaming it here.

dunxen avatar May 03 '24 09:05 dunxen

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.

passcod avatar May 03 '24 11:05 passcod

Going to note that github has released this https://github.blog/2024-05-02-introducing-artifact-attestations-now-in-public-beta/

he, literally published yesterday! Thanks, this might be what we want so I'll look into it as well.

dunxen avatar May 03 '24 11:05 dunxen

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!

ashleygwilliams avatar May 03 '24 14:05 ashleygwilliams

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 :)

dunxen avatar May 04 '24 04:05 dunxen

Hey folks following this 👋

After the initial support of GitHub Artifact Attestations landed (thanks all for the review 🙏), I'm still keen on working on this issue fully to allow a custom signing setup via sigstore-rs. I've been a bit busy with my main open source projects work, but would love to still help out here if people desire something beyond just using GitHub to create the attestations for you. I'd imagine that is still the case!

dunxen avatar Jul 23 '24 15:07 dunxen