Skip to content

Conversation

@jeffwidman
Copy link
Member

@jeffwidman jeffwidman commented Apr 10, 2025

This adds sigstore attestations for our published gems.

We do not need to provide an OIDC token to the sigstore client because by default it will request the token from the GitHub Actions environment: https://github.com/sigstore/sigstore-ruby/blob/9ac72d3c27edcd791c8c831316447f0ab7dfb407/cli/lib/sigstore/cli/id_token.rb#L45-L68

The code inspiration for this change came from:

You can see an example attestation here: https://rubygems.org/gems/sigstore/versions/0.2.1

Related:

@jeffwidman
Copy link
Member Author

jeffwidman commented Apr 10, 2025

I haven't tested this directly because I didn't want to futz around with trying to setup OIDC tokens in a local environment...

Since OIDC tokens are already built into GitHub Actions, and this seemed so straightforward, and even if it doesn't work it's not hard to fixup and then re-tag a new version...

Given all that, I figure it's much simpler to test by tagging a new release.

Copy link
Member

@JamieMagee JamieMagee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you! Once this is complete you'll be able to verify that both the ruby gems and the container images are published from this repository.

sleep(2)
begin
sh "gem push #{gem_path}"
sh "gem exec sigstore-cli:0.2.1 sign #{gem_path} --bundle #{gem_attestation_path}"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a way we can avoid pinning the sigstore-cli version? We might forget to update it

Copy link
Member Author

@jeffwidman jeffwidman Apr 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, good shout--I'm not super excited about pinning...

Given that we only push every week or two, and if it breaks it's not hard to fix and re-push, then I wonder if we could simply pin to latest? I don't know enough about Sigstore expectations to know if that's a good/bad idea... 🤷‍♂️

If we do want to pin to a version, we could do some hackery with a formal Gemfile and Gemfile.lock such that :dependabot: could auto-bump the versions, but I'd personally rather keep this lightweight for now... especially given there's a chance we may refactor this entire Rakefile away in the not too distant future:

So I'm tempted to ship this now, then modify the version pinning as a follow-on as we learn more... unless we are really confident we can skip version pinning altogether?

Nishnha
Nishnha previously approved these changes Apr 10, 2025
Copy link
Member

@Nishnha Nishnha left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. I left a couple of minor comments

jeffwidman and others added 2 commits April 10, 2025 13:51
This adds sigstore attestations for our published gems.

We do not need to provide an OIDC token to the sigstore client because
by default it will request the token from the GitHub Actions environment:
https://github.com/sigstore/sigstore-ruby/blob/9ac72d3c27edcd791c8c831316447f0ab7dfb407/cli/lib/sigstore/cli/id_token.rb#L45-L68

The code inspiration for this change came from:
* 84codes/rubocop-eightyfourcodes#16
* rubygems/release-gem#11

You can see an example of how this attestation will look on RubyGems here:
https://rubygems.org/gems/sigstore/versions/0.2.1
Co-authored-by: Nish Sinha <nishnha@github.com>
@jeffwidman jeffwidman force-pushed the add-sigstore-attestations-for-rubygems branch from 44499c0 to 7986316 Compare April 10, 2025 20:51
@jeffwidman jeffwidman merged commit f0c1d2e into main Apr 10, 2025
65 checks passed
@jeffwidman jeffwidman deleted the add-sigstore-attestations-for-rubygems branch April 10, 2025 21:03
@jeffwidman
Copy link
Member Author

IT WORKS! (after merging #12036)

image

@JamieMagee
Copy link
Member

@jeffwidman thank you!

Unfortunately, there isn't a built-in way for Bundler to verify gem signatures. It can be done manually using rekor. But, this checks off one more part of our supply chain that is signed. By my count:

Then we can start enforcing signature verification:

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants