Sigstore has become the de-facto signing approach for modern package registries, with PyPI shipping attestations in 2024 and npm having supported provenance statements since April 2023. RubyGems.org has been working on its own integration for the better part of two years, and the conversation around it has moved in fits and starts. As of the September 2024 snapshot, some pieces are live, others are still in RFC discussion, and the path to mandatory signing is further out than many hoped. This post walks through the actual state of the work, separating what has shipped from what is aspirational.
The backdrop is that Ruby Central, which took over operational responsibility for RubyGems.org in 2022, has limited paid engineering capacity dedicated to registry improvements. Most of the work happens through volunteers or through grants that fund specific milestones. That shapes the pace in ways worth understanding.
What has actually shipped?
RubyGems.org added trusted publishing via OpenID Connect in December 2023, which was the foundational step that Sigstore signing depends on. When a GitHub Actions workflow publishes a gem through the trusted publisher path, RubyGems.org receives an OIDC token that asserts the repository, workflow, and commit SHA that triggered the publish. This metadata is captured server-side and exposed on the gem's public page. You can see it today for gems like ruby-lsp and sorbet-runtime that adopted trusted publishing early.
What is not yet shipped is the actual Sigstore signing and verification flow. A trusted publisher today asserts an OIDC identity but does not produce a Sigstore bundle alongside the gem artifact. The sigstore-ruby gem, maintained largely by Segiddins and contributors, landed its 0.2.0 release in June 2024 with support for signing and verifying arbitrary blobs using Fulcio and Rekor, but the integration with the RubyGems publish flow is still a work in progress. The remaining engineering covers how to store the bundle, how to expose it to Bundler clients, and how to migrate existing gems without breaking older clients.
What is in active RFC?
There are three open RFCs as of September 2024 that cover the Sigstore story. The first addresses the format of the signature bundle itself and whether to use Sigstore's standard bundle format or a RubyGems-specific wrapper. The argument for the standard format is interoperability with existing tooling; the argument against is that Bundler would need to carry additional code to parse it, which meaningfully slows down install operations in large Gemfiles. The current leaning is toward the standard format with careful optimization in Bundler to keep install time reasonable.
The second RFC covers client-side verification defaults. Opt-in verification is easy: a maintainer-facing flag in .gemrc or an environment variable flips on Sigstore verification for any gem that has a bundle. Mandatory verification is much harder because a meaningful chunk of gems will never be signed. The current proposal is a staged rollout: warnings in Bundler 2.6 for gems missing bundles that were recently published by a trusted publisher, then opt-in hard verification in Bundler 2.7, with a many-year horizon before any mandatory behavior.
The third RFC covers key rotation and revocation, which is the topic that has generated the most discussion. Sigstore's short-lived certificates issued by Fulcio naturally handle most rotation concerns, but the question of what happens when a maintainer account is compromised, and an attacker signs a malicious gem version through trusted publishing, remains unsettled. The leading proposal is a Rekor-backed revocation list that clients consult on verify, but the latency and privacy implications are still being debated.
How are early-adopter gems using it?
Even without full Sigstore integration, several gems have adopted the trusted-publishing-plus-workflow-attestation path in a way that gives consumers something close to signing semantics. ruby-lsp, sorbet-runtime, rubocop-ast, and a handful of others publish through GitHub Actions workflows that produce SLSA provenance attestations alongside the gem. The attestation is stored as a GitHub release asset and linked from the gem's README.
This is not a full Sigstore integration, but it is enough for a cautious consumer to write a verification step that fetches the attestation, checks that the provenance claims match expectations, and fails the build if anything drifts. Several enterprise Ruby teams have built internal tooling around this pattern as a stopgap while the native RubyGems support matures. The tooling is not widely published, but conversations at RailsConf 2024 suggested that at least a dozen large organizations have implemented something along these lines.
What does this mean for gem maintainers today?
If you maintain a gem and want to be ready for the Sigstore future, the most valuable step is to adopt trusted publishing now. The setup involves configuring an OIDC trust relationship between RubyGems.org and your GitHub Actions workflow, which the RubyGems documentation walks through in detail. Once configured, you remove long-lived API tokens from your repository secrets and the workflow publishes through the OIDC token instead. This is immediately valuable for security independent of Sigstore, and it positions your gem to pick up signing automatically when the feature ships.
The second step is to review your release workflow for reproducibility. Sigstore signing is most valuable when a third party can recompute the artifact you published and verify that the signature matches what their build produced. Gems with deterministic build processes, no embedded timestamps, no platform-specific binary artifacts, no network calls during build, are much easier to verify meaningfully. Most pure-Ruby gems are already close to this. Gems with native extensions are not, and that is a harder conversation covered in other posts in this series.
The third step is to keep the sigstore-ruby gem on your radar. It works today for signing arbitrary files in your release pipeline, and some maintainers have started publishing ad-hoc Sigstore bundles as a GitHub release asset even though RubyGems.org does not yet consume them. This is not a substitute for the eventual registry integration, but it creates an audit trail and exercises the tooling.
What should consumers do?
Consumers of gems have less leverage today than they will in 12 to 18 months. The pragmatic move is to track which of your dependencies have adopted trusted publishing and prioritize those in any vendor-risk review. The rubygems-trusted-publishing-status community script, published as a gist by several Ruby security researchers, walks your Gemfile.lock and annotates each gem with its trusted-publishing status based on the RubyGems.org API. The current numbers are sobering: in a typical Rails application with 180 or so gems in its lockfile, about 9 will show trusted publishing configured, with the rest still using long-lived API tokens.
This is not an indictment of those gems. Adopting trusted publishing takes effort, and smaller gems without a dedicated maintainer will lag. But it is a useful signal about which parts of your dependency tree have up-to-date security hygiene, and it informs where you invest additional controls like SBOM monitoring and behavioral detection.
Where does the timeline stand?
Based on the current trajectory, basic Sigstore signing support in RubyGems.org is likely in the first half of 2025, with Bundler client support following by mid-2025. Mandatory signing for any meaningful subset of gems is probably 2027 or later, and a fully-verified registry like the npm or PyPI aspirational models is further still. These are estimates, not promises, and they depend on whether Ruby Central can secure continued funding for the effort. The community should weigh in where it can, especially on the RFCs, because the decisions being made now will shape the next decade of Ruby supply-chain security.
How Safeguard Helps
Safeguard tracks the trusted-publishing and provenance posture of every gem in your Gemfile.lock, surfacing which of your dependencies are using modern signing paths and which rely on older token-based publishing. When Sigstore verification becomes available in Bundler, we will integrate bundle verification into our scanning pipeline so you can enforce a policy of signed-only dependencies across your fleet. For the interim period, we correlate GitHub SLSA attestations against published gems and alert when a gem publishes outside its normal trusted-publisher path, giving you early warning of maintainer compromise even before registry-level signing exists.