Use trusted publishing for Cargo crates

[Kobzol]

Companion to rust-lang/team#2727. This is done to improve publishing security, and allow us to track Cargo crates in the team database.

CC @Mark-Simulacrum (probably you'll want to wait until the next release? or we can test drive it tomorrow on 1.98.1 :) )

CARGO_REGISTRY_TOKEN should be removed from this repository once this PR is merged.

[rustbot]

r? @epage

rustbot has assigned @epage.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @epage, @weihanglo
• @epage, @weihanglo expanded to epage, weihanglo
• Random selection from epage, weihanglo

[epage]

With this, is manual token publishing being removed? We occasionally need to do one-off publishes and don't have CI setup for that. Granted Eric was the only one who could do that and unsure if he handed that off to anyone else.

[Kobzol]

The whole idea of trusted publishing is to publish only from CI, yeah. How did the one-off publishes work? We can still make the publish process be manually triggered, e.g. by clicking on a workflow in the GitHub UI.

[epage]

The whole idea of trusted publishing is to publish only from CI, yeah.

No, trusted publishing is about providing a more secure way to publish from an automated system and does not convey any more trust than local, manual publishing. The name is very confusing. See also https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing. William Woodruff and I talked about this on Zulip when they were proposing to add it to crates.io.

[epage]

We can still make the publish process be manually triggered, e.g. by clicking on a workflow in the GitHub UI.

Eric handled it. The current workflow is insufficient because it is designed for releases and doesn' handle things like home.

[Kobzol]

The whole idea of trusted publishing is to publish only from CI, yeah.

No, trusted publishing is about providing a more secure way to publish from an automated system and does not convey any more trust than local, manual publishing. The name is very confusing. See also https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing. William Woodruff and I talked about this on Zulip when they were proposing to add it to crates.io.

I'm aware of that discussion :) And I agree that the name is not ideal, but the point is still the same, you have to publish from CI (meaning, if we move forward with the infra plan, it just won't be possible to publish otherwise). So we should figure out how to make that work for all use-cases of t-cargo.

Eric handled it. The current workflow is insufficient because it is designed for releases and doesn' handle things like home.

We can add parameters to the workflow, e.g. in the GitHub UI you can run it manually and select which crates to publish via a comma-separated list. Or we could add a script that will do the same.

[weihanglo]

Eric handled it. The current workflow is insufficient because it is designed for releases and doesn' handle things like home.

We can add parameters to the workflow, e.g. in the GitHub UI you can run it manually and select which crates to publish via a comma-separated list. Or we could add a script that will do the same.

Yes, home is the only thing left. Other are handled by t-release. I don't expect any meaningful release in the future for home. Maybe we should discontinue home and instead create a new repo called rustup-cargo-home co-owned by t-rustup and t-cargo, so we don't need to deal with this out-of-band publish in rust-lang/cargo repo.

[Kobzol]

I think that's a bit orthogonal to using trusted publishing, but in general moving that crate to a separate repository sounds like a useful cleanup on its own, at least to me.

[weihanglo]

With this, is manual token publishing being removed? We occasionally need to do one-off publishes and don't have CI setup for that. Granted Eric was the only one who could do that and unsure if he handed that off to anyone else.

Handed off to me (as you can see I am one of the owner).

Some packages are not published automatically because they are not part of the Rust release train. This currently only includes the home package. These are published manually on an as-needed or as-requested basis by whoever has permissions (currently @ehuss or the Release/Infra team)2.

home is the only crate needing manual publish. That was why I think home simplifies adding trusted publishing workflow to cargo.

[Kobzol]

Ah, ok. If home is indeed the only one, and otherwise Cargo is always published through tags, then that would indeed simplify things. But we can still add support for manual publishes to Cargo if needed :)

[weihanglo]

The conclusion in #t-cargo > discontinue `home` and a new rustup-cargo-util shared repo is kinda we probably want to keep home or future cargo-util-home in the same repo, so still needs some manual-publish escape hatch.

[Kobzol]

Home wasn't published by this GHA workflow anyway, right? So we just won't add it to the team repo yet, and then nothing changes for it.

[arlosi]

Thanks! We talked about this in the Cargo meeting today and agreed to move forward.

View changes since this review

[ubiratansoares]

FYK : I removed CARGO_REGISTRY_TOKEN from the release environment. Token invalidation to follow