controllers/krate/publish: Add support for Trusted Publishing access tokens

[Turbo87]

This is the last major missing puzzle piece for the Trusted Publishing backend work: the ability to use temporary access tokens to publish new versions of crates.

Related:

• Tracking Issue for "Trusted Publishing Support" #10247
• crates.io: Trusted Publishing Support rfcs#3691
• Create "Trusted Publishing" database tables #11062
• Add PUT /api/v1/trusted_publishing/github_configs API endpoint #11113
• Add PUT /api/v1/trusted_publishing/tokens API endpoint #11131

[LawnGnome]

A couple of non-binding suggestions, but LGTM in general. I like the new trustpub test, in particular! :+1

[eth3lbert]

🙋 I was wondering if we could use the creator of the trustpub config as published_by but then I realized we don't record that information 😅. Is this a bad idea, or are we not supposed to do it this way?

[Turbo87]

I think that could be misleading, since it is not the person that triggered the release itself. It might be possible to figure out the releaser from the actor or actor_id fields of the JWT, but that seems like a future enhancement to me and it would also only work for GitHub Actions, but not for GitLab CI or other Trusted Publishers.

[eth3lbert]

🙋 Another question came up. I noticed that only the regular (non-TrustPub) AuthType requires a verified email for publishing, while the TrustPub AuthType does not seem to require this. Would it be bad to ensure email is verified before creating a trustpub config?

[Turbo87]

Would it be bad to ensure email is verified before creating a trustpub config?

yeah, we should probably implement that 👍

[eth3lbert]

🙋 A random question just came to mind. IIUC, the supported issuer is checked during the key exchange stage. This means that once they've exchanged the token, they can then ensure to publish a new version with it this time, even if we were to roll back support for this issuer right after the exchange, right?

[Turbo87]

they can then ensure to publish a new version with it this time, even if we were to roll back support for this issuer right after the exchange, right?

yes, that's how it's currently implemented. I guess if we wanted to change that we would need back-references from the temporary tokens to their configurations (i.e. one nullable column per provider?) and set them to "on delete cascade".