A credential provider plugin for trusted publishing

[weihanglo]

Problem

Trusted publishing is generally available today. It hardens the CI publish workflow a lot. However, cargo publish by default performs a verification for your package before the actual crates.io publish/upload. Cargo currently compiles the package as part of the verification step. That means the lifetime of the temporary publish token generated by crates-io-auth-action lives unnecessarily longer than the actual publish step .

The situation might get worse when -Zpackage-workspace (be able to publish the entire workspace) is stabilized.

The situation is a lot better than old days, we can look at what Cargo can do to help minimize the life time of the publish token, hardening the security even more.

Proposed Solution

A solution around leveraging Cargo's credential provider has been brought up: rust-lang/rfcs#3691 (comment).

Basically we can create a credential provider plugin that hooks into the publish request, and prepare the token right before the publish. Let me repost the flowchart here

sequenceDiagram
    participant D as Developer
    participant Cargo
    participant COP as cargo-oidc-provider<br/>(built-in or installed from GH Action)
    participant OIDC as GH OIDC Provider
    participant C as crates.io
    
    D->>Cargo: 1. Trigger release workflow
    rect rgb(253, 253, 150)
    note right of Cargo: cargo publish
    Cargo->>+COP: 0. Read operation<br/>(not important to crates.io)
    COP-->>-Cargo: Respond to Read operation
    Cargo-->>Cargo: Build artifact
    Cargo->>+COP: 1. Publish operation

    COP->>+OIDC: 2. Authenticate & request signed ID token
    OIDC-->>-COP: 3. Return signed ID token
    COP->>+C: 4. Send ID token & request access token
    C-->>C: 5. Verify validity of ID token using GHA OIDC's public keys
    C-->>-COP: 6. Return temporary access token
    COP-->>-Cargo: 7. Respond to Publish operation
    Cargo->>+C: 8. Publish artifact with access token
    C-->>-Cargo: Publish success
    end

    rect rgb(253, 253, 150)
    note right of Cargo: cargo logout<br/>(remote logout not implemented)
    Cargo->>+C: 9. Request revocation of access token
    C-->>-Cargo: Confirm revocation of access token
    
    end

Loading

Notes

A immediate problem of this approach is that the workflow of publish doesn't have a post action for us to revoke the token. We might need an extra post-publish hook. Unsure if that requires a version bump of the protocol (I guess yes?)

[weihanglo]

Some design questions:

• Should this credential provider plugin be built-in in Cargo?
  • Pros
    • No need to install extra stuff. Less step = Higher adoption rate
  • Cons
    • Bloat the cargo binary size
    • The development will be tied to Rust releases
• Should we generalize the credential provider plugin to accept different publisher, e.g., GitLab?
  • PyPI supports 4 different publisher as of 2025-07 https://docs.pypi.org/trusted-publishers/adding-a-publisher/

[epage]

Sounds like we'd need to have support for specific publishers? We'd need to carefully decide what our compatibility guarantees for this would be and what the approval process is for someone adding one. Maybe a tier system like platforms?

What are the security risks with something like this? Would a separate provider be beneficial in terms of deploying security fixes?

[weihanglo]

Sounds like we'd need to have support for specific publishers?

Assume you were talking about supports in crates.io, then yes. If Cargo is going to support it natively as built-ins, tier system and/or policy must be set.

My initial idea of having it built-in is to make it "zero configuration" to use the feature. However, I don't think there is a reliable way for Cargo to detect whether it should perform "trusted publish." Checking the GITHUB_ACTIONS environment variable? That will be too much depended on a feature of an external service. To avoid that, we still need a way to inform cargo publish to do trusted publish. And the best way IMO is still using GitHub Actions to set some environment variable Cargo agrees with.

Given we regardless need a GitHub Action to inform cargo publish, I think a standalone credential provider plugin is a better choice.

Would a separate provider be beneficial in terms of deploying security fixes?

Yes. One plugin per provider seems better in terms of deploying security fixes.

[epage]

Checking the GITHUB_ACTIONS environment variable? That will be too much depended on a feature of an external service. To avoid that, we still need a way to inform cargo publish to do trusted publish. A

So I assume that way would be to configure a trusted publishing credential provider, whether built-in or third-party?

Yes. One plugin per provider seems better in terms of deploying security fixes.

Unsure about plugins per provider, I was more thinking of the difference between rolling out changes for a semi-official program that is light on process and doing an entire Rust release.

[weihanglo]

So I assume that way would be to configure a trusted publishing credential provider, whether built-in or third-party?

Yes, we'll need to configure

• GitHub OIDC token endpoint
• crates.io token endpoint

And if it we have it built-in, the workflow will be tied with a certain Rust version. Security issues might come from unrelated parties. Bumping MSRV for just fixing those seems a bit overkill.

[bjorn3]

Could the rust-lang/crates-io-auth-action action ship the credential provider plugin? So rather than it immediately creating a token to be passed to cargo through CARGO_REGISTRY_TOKEN, it would configure itself as credential provider in ~/.cargo/config.toml.

[weihanglo]

Could the rust-lang/crates-io-auth-action action ship the credential provider plugin?

It is exactly what I was thinking. Love to see it happen.

[weihanglo]

The simplest implementation of this would be: In credential provider protocol v2, cargo will send a publish-completion/logout action to the credential provider plugin, and the plugin will perform the logout.

However, given -Zpackage-workspace has been stabilized, we might want to change how the "publish" credential operation is fired in Cargo. Otherwise, the credential provider plugin will request OIDC and publish token on per-crate basis, and that is too costly.

• Should we have news operation like BulkPublishStart and BulkPublishEnd in the protocol to inform the plugin the workspace publish is about to start?
• Instead of Cargo being stateful, should the plugin be stateful and keep the token somewhere temporarily (sounds bad).

It sounds like a separate issue though, as it is addressing the change needed for workspace-publish, though if we are going to ship breaking changes, we'd better do all of them in one bump rather than two.