Skip to content
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

Open
rgreinho opened this issue Feb 12, 2023 · 12 comments
Open

sign binaries with sigstore #120

rgreinho opened this issue Feb 12, 2023 · 12 comments

Comments

@rgreinho
Copy link

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.

@ashleygwilliams ashleygwilliams added the feature request New feature or request label Feb 16, 2023
@ashleygwilliams ashleygwilliams added this to the next milestone Feb 16, 2023
@Gankra
Copy link
Member

Gankra commented Feb 16, 2023

possible dupe of #21

@Gankra Gankra changed the title Support signing binaries sign binaries with sigstore Feb 16, 2023
@Gankra
Copy link
Member

Gankra commented Feb 16, 2023

(making this a more specific task)

@passcod
Copy link

passcod commented Mar 17, 2023

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

@Gankra
Copy link
Member

Gankra commented May 10, 2023

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

@dunxen
Copy link

dunxen commented May 13, 2023

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

@passcod
Copy link

passcod commented May 13, 2023

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

@dunxen
Copy link

dunxen commented May 13, 2023

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.

@Gankra Gankra removed this from the 0.1.0 milestone Jul 20, 2023
@dunxen
Copy link

dunxen commented May 3, 2024

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.

@passcod
Copy link

passcod commented May 3, 2024

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.

@dunxen
Copy link

dunxen commented May 3, 2024

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.

@ashleygwilliams
Copy link
Member

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!

@dunxen
Copy link

dunxen commented May 4, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants