Are we Trusted Publishing yet?

Thousands of Dart community members publish packages on pub.dev, for the benefit of all Dart and Flutter developers. Traditionally, these package publishers have published to pub.dev by running a local terminal command, dart pub publish, and authenticating with their Google account. Behind the scenes a refresh token was stored in a configuration file on their development machine, which enabled them to publish a new version without authenticating again. This flow is simple and easy to understand, but requires a number of manual steps. We’re happy to introduce a new automated publishing flow, that enables publishing new pub.dev versions directly from a GitHub Action. This has several benefits:

• Each release is automatically tagged with consistent release tags in GitHub
• It’s easy to configure a review and approval flow for publishing new versions.
• The publishing process is authenticated by a token signed by GitHub, ensuring no credentials have to be stored on disk.

"Trusted publishing" is our term for using the OpenID Connect (OIDC) standard to exchange short-lived identity tokens between a trusted third-party service and PyPI. This method can be used in automated environments and eliminates the need to use username/password combinations or manually generated API tokens to authenticate with PyPI when publishing.

Enter the subject of today’s announcement: Trusted Publishing. Before getting into the details, I’d like to quickly thank our friends over at PyPI for blazing this trail, providing helpful guidance, and writing some pretty great docs.

Trusted Publishing is a term for using OpenID Connect (OIDC) to exchange short-lived identity tokens between a trusted third-party service and RubyGems.org. This allows obtaining short-lived API tokens in an automated environment (such as CI) without having to store long-lived API tokens or username/password credentials.

After filling out four form fields for your gem (repo owner, repo name, GitHub Actions workflow file name, and optional GitHub Environment), you’ll be able to automate publishing via GitHub Actions with a short, simple, and copy/pastable workflow.

PyPI package maintainers can publish via Trusted Publishing from three additional providers (in addition to GitHub Actions):

• GitLab CI/CD
• Google Cloud
• ActiveState

• PyPI Blog: Expanding Trusted Publisher Support

We are excited to announce that we have implemented "Trusted Publishing" support on crates.io, as described in RFC #3691. This feature was inspired by the PyPI team's excellent work in this area, and we want to thank them for the inspiration!

Trusted Publishing eliminates the need for GitHub Actions secrets when publishing crates from your CI/CD pipeline. Instead of managing API tokens, you can now configure which GitHub repository you trust directly on crates.io. That repository is then allowed to request a short-lived API token for publishing in a secure way using OpenID Connect (OIDC). While Trusted Publishing is currently limited to GitHub Actions, we have built it in a way that allows other CI/CD providers like GitLab CI to be supported in the future.

With trusted publishing, you can now:

• Publish packages without npm tokens: Configure your packages to accept publishes from specific GitHub Actions or GitLab CI/CD workflows using OIDC authentication.
• Eliminate token security risks: No more storing, rotating, or accidentally exposing npm tokens in your CI/CD environments.
• Establish cryptographic trust: Each publish is authenticated using short-lived, workflow-specific credentials that cannot be exfiltrated or reused.
• Get automatic provenance: When using trusted publishing, npm CLI publishes provenance attestations by default. The --provenance flag is no longer needed.

Trusted Publishing is a better way to publish NuGet packages. You don’t need to manage long-lived API keys anymore. Instead, you use short-lived credentials issued by your CI/CD system, like GitHub Actions.

This makes your publishing process safer by reducing the risk of leaked credentials. It also makes automation easier because you don’t need to rotate or store secrets. This approach is part of a broader industry shift toward secure, keyless publishing. If you're curious, check out the OpenSSF initiative.