Upload attestation of gem provenance at release

[dentarg]

Since last year, RubyGems.org accepts Sigstore Bundles with Gem Pushes: https://github.com/rubygems/rfcs/blob/33b5ebddeb161e847cd950cc77fbaf667ff180bd/text/0000-rubygems.org-sigstore-bundles.md

This uses sigstore-cli[1][2] to generate a sigstore bundle[3] that we include in the push to RubyGems.org.

I got this command from rubygems/release-gem#11 I've tested this over at https://rubygems.org/gems/slenips https://github.com/spinels/slenips/blob/ae7cc4fa6d777f49ea0860acf0426b187c50a1fe/.github/workflows/release.yml#L25-L32

See also

• https://segiddins.github.io/are-we-attested-yet/
• https://blog.rubygems.org/2025/03/19/february-rubygems-updates.html
• https://blog.trailofbits.com/2024/11/14/attestations-a-new-generation-of-signatures-on-pypi/

1: https://github.com/sigstore/sigstore-ruby
2: https://rubygems.org/gems/sigstore-cli
3: https://docs.sigstore.dev/about/bundle/

[dentarg]

I'm intentionally not using the rubygems/release-gem action, because I don't like the way it is doing things; it assumes you use the Bundler rake release task. I like to be more in control and not depend on that task (and know what that task is doing). There's a few issues open about this and other things: https://github.com/rubygems/release-gem/issues

[dentarg]

it assumes you use the Bundler rake release task. I like to be more in control and not depend on that task (and know what that task is doing)

For example, it tries to push the tag (in a specific format) to your git repo.

[dentarg]

I've tested this over at https://rubygems.org/gems/slenips https://github.com/spinels/slenips/blob/ae7cc4fa6d777f49ea0860acf0426b187c50a1fe/.github/workflows/release.yml#L25-L32

Example sigstore bundle for the curious: https://gist.github.com/dentarg/3133c87d404c951d47298aa9c08ff829

[dentarg]

I'm intentionally not using the rubygems/release-gem action, because I don't like the way it is doing things; it assumes you use the Bundler rake release task. I like to be more in control and not depend on that task (and know what that task is doing). There's a few issues open about this and other things: https://github.com/rubygems/release-gem/issues

I missed that this gem do use bundle exec rake release 🙈 It is in the README. I'll make the new release what we have now, just to get it out the door.

[walro]

I missed that this gem do use bundle exec rake release 🙈 It is in the README. I'll make the new release what we have now, just to get it out the door.

Lazy reviewer just bought your reasoning too 😁

[dentarg]

I do like that we record who pushed the tag in git

$ git sorted-tags-with-body
2025-03-20 8e6123d v0.0.4 (Patrik Ragnarsson) []
Version 0.0.4

2024-10-23 6008016 v0.0.3 (Anders Bälter) []
Version 0.0.3

Instead of it being pushed by "GitHub Actions" (maybe it is possible to configure that, dunno)

[dentarg]

I'm thinking we stick to the way it is now: #18

[jeffwidman]

I'm curious... why did you do ruby -S here, versus all the other calls you do gem exec by itself?

[dentarg]

I just copied that from the rubygems/release-gem action: https://github.com/rubygems/release-gem/pull/11/files#diff-bbc4dcfa3b9d8c948a1e28efe575fb30910f0f05057fb22735e2245e90a0cbd8R40-R43

I'm not sure it is needed, I didn't think much of it. Actually, I never looked up what -S does, as I trusted @segiddins to know his shit :)

     -S             Makes Ruby use the PATH environment variable to search for
                    script, unless its name begins with a slash.  This is used
                    to emulate #! on machines that don't support it, in the
                    following manner:

                          #! /usr/local/bin/ruby
                          # This line makes the next one a comment in Ruby \
                            exec /usr/local/bin/ruby -S $0 $*

                    On some systems $0 does not always contain the full
                    pathname, so you need the -S switch to tell Ruby to search
                    for the script if necessary (to handle embedded spaces and
                    such).  A better construct than $* would be ${1+"$@"}, but
                    it does not work if the script is being interpreted by
                    csh(1).

Sounds like it doesn't really make sense on the command line, like here, but when using Open3.capture2e it makes more sense?

How did you find this PR @jeffwidman? :)

[jeffwidman]

Stumbled across it while researching dependabot/dependabot-core#12025 😄