by Tobias Bieniek: Rust Foundation
In April 2025, I began working on what would become one of the most significant security improvements to come to crates.io in recent years. The challenge was clear: eliminate the risks of long-lived API tokens while streamlining the release process for Rust developers. Two years after PyPI pioneered trusted publishing, we’ve successfully brought this game-changing security feature to the Rust ecosystem.
For years, Rust developers publishing packages to crates.io faced a familiar dilemma: store sensitive API tokens in CI/CD systems or manually publish from their development machines. These tokens, often valid without any expiry date, could be accidentally exposed, stolen, or misused if they fell into the wrong hands. Even with GitHub’s Secret Scanning integration, the window between exposure and revocation provided attackers with opportunities for supply chain attacks.
Working closely with Matthew Trostel, who authored the initial RFC, and drawing inspiration from William Woodruff’s pioneering work on PyPI’s implementation, we set out to solve this problem using OpenID Connect (OIDC) and trusted publishing.
What is Trusted Publishing?
Trusted publishing replaces traditional long-lived API tokens with short-lived access tokens generated through cryptographically verified identity claims. Instead of manually creating and storing secrets, developers configure crates.io to trust specific GitHub Actions workflows from their repositories. When these workflows run, they can automatically obtain temporary publishing permissions without any stored credentials.
The concept builds on OpenID Connect, a federated authentication protocol that allows unrelated services to verify identities through cryptographic signatures. In our implementation, GitHub Actions serves as the identity provider, creating signed tokens that prove a workflow’s identity, while crates.io acts as the relying party, verifying these tokens and exchanging them for temporary access credentials.
This approach follows OpenSSF’s Principles for Package Repository Security and builds on the success we’ve seen in other ecosystems. PyPI has seen over 39,000 projects adopt trusted publishing since its launch, and RubyGems has followed suit with their own implementation.
The Implementation Journey
The path to trusted publishing began with RFC 3691, which Matthew Trostel drafted in April 2024. By September, we had opened the RFC for community discussion, and it was officially accepted in December 2024. The technical work started in earnest in April 2025.
The most challenging aspect wasn’t the OIDC implementation itself – the protocol is well-established and documented. Instead, the complexity lay in adapting PyPI’s proven design to crates.io’s architecture and ensuring a smooth migration path for existing users.
Following PyPI’s approach, we require explicit workflow file names in the trusted publisher configuration. PyPI had already demonstrated that while this adds a setup step, it significantly reduces the attack surface by ensuring only specific workflow files can publish packages, even if an attacker compromises other parts of a repository.
We also adopted PyPI’s pattern of exchanging OIDC identity tokens for registry-specific access tokens rather than using ID tokens directly for API authorization. This approach provides consistency in authorization logic across different identity providers and ensures that existing security integrations, like Secret Scanning, continue to work effectively.
How It Works in Practice
Setting up trusted publishing is a one-time configuration per crate. After the initial manual publish, crate owners can visit their crate’s settings page and configure a trusted publisher by specifying:
- The GitHub organization or username
- The repository name
- The workflow file name (must be in .github/workflows/)
- Optionally, a specific GitHub Actions environment
Once configured, a typical publishing workflow looks remarkably simple:
name: Publish Crate
on:
release:
types: [published]
jobs:
publish:
runs-on: ubuntu-latest
environment: release # Optional but recommended
permissions:
id-token: write # Required for OIDC
steps:
- uses: actions/checkout@v5
- name: Authenticate with crates.io
id: auth
uses: rust-lang/crates-io-auth-action@v1
- name: Publish to crates.io
run: cargo publish
env:
CARGO_REGISTRY_TOKEN: ${{ steps.auth.outputs.token }}
Behind the scenes, this workflow triggers a sophisticated but seamless process:
- GitHub Actions requests a signed identity token from GitHub’s OIDC provider
- The workflow sends this token to crates.io to exchange for an access token
- crates.io validates the token signature using GitHub’s public keys
- A temporary access token is generated and returned
- The workflow uses this token for cargo publish
- The token is automatically revoked after the workflow completes
This entire flow happens without any stored secrets, and each token is cryptographically tied to the specific workflow, repository, and run context.
Security Benefits and Real-World Impact
The security improvements are substantial. We’ve eliminated the need for long-lived API tokens in CI/CD systems, removing a significant attack vector for supply chain compromises. Tokens are now scoped to specific repositories and workflows, automatically expire within minutes, and require no manual creation or rotation.
Since our full rollout in July 2025, adoption has been encouraging. Over 770 packages have configured trusted publishing, including high-profile projects like pyo3 and the cc crate. Several crates from the Rust project itself have also adopted the feature. The feedback from developers has been overwhelmingly positive. They appreciate both the security improvements and the simplified release workflows.
The community response has been positive, with developers appreciating the elimination of manual token management and the reduced risk of credential exposure. The phased rollout approach, starting with GitHub Actions, has allowed us to gather feedback and refine the experience before expanding to additional CI platforms.
What’s Next
While GitHub Actions support provides the foundation, we’re already planning for the future. GitLab CI/CD support is next on our roadmap, which will validate that our OIDC-based architecture can scale to serve the broader Rust community across different CI ecosystems.
The success of this implementation demonstrates the power of collaborative security improvements in open source ecosystems. By following established patterns from other package registries and working closely with security experts, we’ve been able to deliver a feature that meaningfully improves the security posture of the entire Rust ecosystem.
Acknowledgments
This work wouldn’t have been possible without the collaboration and support of many people and organizations. Matthew Trostel authored the original RFC and provided design guidance throughout the implementation. William Woodruff, who implemented trusted publishing for PyPI, generously shared his expertise and reviewed our implementation approach.
The entire crates.io team provided thoughtful code reviews and feedback that improved both the implementation and user experience. The Alpha-Omega project’s funding made this security improvement possible, demonstrating their commitment to strengthening open source supply chains.
I’m also grateful to the PyPI team for pioneering this approach and openly sharing their learnings, and to the Rust community for their enthusiasm and constructive feedback throughout the development process.
Trusted publishing represents more than just a new feature, it’s a step toward a more secure future for software supply chains. By eliminating long-lived secrets and providing cryptographic verification of publishing authority, we’re helping ensure that the packages developers depend on come from verified, authorized sources.
The shift to trusted publishing is already underway, and I encourage all Rust developers to explore how it can simplify and secure their release workflows. You can get started with our setup guide and join the hundreds of projects already benefiting from this enhanced security model.
Author Bio
Tobias Bieniek is a Software Engineer at the Rust Foundation where he focuses primarily on serving the Rust Project crates.io Team.
