Try out trusted publishing for crates.io

[alexcrichton]

No description provided.

[Turbo87]

thanks for testing! let me know if you have any feedback 😉

[alexcrichton]

Oh sure! Is here a good place to drop some minor thoughts or is there a better location?

[Turbo87]

Is here a good place to drop some minor thoughts

sure, yeah :)

[alexcrichton]

Ok happy to! Overall a really nice feature, I look forward to using in larger repos. Thank you (and others!) for working on it!

Two very minor things I noticed which aren't blockers in any way:

• The email notification about the crate previously had a source of "was published by this person" but using this approach didn't list anything there. Would it be possible to mention the repo/workflow that performed the publish? (or perhaps does crates.io get a link to the actual workflow itself? that'd be pretty neat to have a url right back to the workflow run)
• At https://crates.io/crates/wasm-component-ld/settings/new-trusted-publisher under "Workflow filename" I was initially uncertain whether to say publish.yml or .github/workflows/publish.yml. The documentation here was clear though that publish.yml was correct. Could the text below the box have a "for example ..." indicating that?

And one slightly larger ask:

For larger repositories (e.g. Wasmtime's workspace) one thing we'll want to do is update our script to ensure that all crates in the workspace have a trusted publishing workflow registered. That'll require us to slightly change our development practices where if a new crate is added we won't be able to merge the PR until someone publishes a dummy version of the crate and registers the trusted publishing workflow, but all that seems fine to me. Question for you though, is there a way to discover through the crate.io API whether there's a trusted publishing workflow registered for a crate? That would be something our script would curl and check to use to prevent merging PRs that add new crates which don't have the trusted publishing workflow set.

[Turbo87]

The email notification about the crate previously had a source of "was published by this person" but using this approach didn't list anything there. Would it be possible to mention the repo/workflow that performed the publish?

I'll need to do some research, but I think that should be possible to some degree.

At https://crates.io/crates/wasm-component-ld/settings/new-trusted-publisher under "Workflow filename" I was initially uncertain whether to say publish.yml or .github/workflows/publish.yml. The documentation here was clear though that publish.yml was correct. Could the text below the box have a "for example ..." indicating that?

I thought I had included that, but apparently it got lost somehow. I'll add it back 👍

is there a way to discover through the crate.io API whether there's a trusted publishing workflow registered for a crate?

generally yes, but since we're still testing and haven't committed to the API design yet the APIs are currently limited to cookie-only authentication so that our frontend is the only API user allowed. once we're feeling confident about the design we will likely open the API up to API token auth too.

[alexcrichton]

Nice, and sounds great! This is all nice enough I might say we should add in the auto-verification in the future and just go ahead and rely on this in the meantime...

Regardless thanks so much again for the work here!

[Turbo87]

I thought I had included that, but apparently it got lost somehow. I'll add it back 👍

• trustpub: Improve config creation form rust-lang/crates.io#11509 :)

[Turbo87]

The email notification about the crate previously had a source of "was published by this person" but using this approach didn't list anything there. Would it be possible to mention the repo/workflow that performed the publish?

• Save and show JWT claims subset when Trusted Publishing is used rust-lang/crates.io#11513

Unfortunately we only get the "run ID" but not the "job ID" from GitHub (see https://docs.github.com/en/actions/concepts/security/about-security-hardening-with-openid-connect), but that still seems reasonably useful :)