Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

Turbo87
Copy link
Member

@Turbo87 Turbo87 commented Jun 4, 2025

@Turbo87 Turbo87 added C-enhancement ✨ Category: Adding new behavior or a change to the way an existing feature works A-backend ⚙️ labels Jun 4, 2025
@Turbo87

This comment was marked as outdated.

Copy link
Contributor

@LawnGnome LawnGnome left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Turbo87 added 2 commits June 6, 2025 10:47
When "Trusted Publishing" is used we can no longer associate the release with a specific crates.io user account. The column is already nullable since old releases did not track the information, so there are no changes needed on the database side.
@Turbo87 Turbo87 force-pushed the trustpub-publish branch from b6bb52b to ded9ab7 Compare June 6, 2025 08:47
@Turbo87 Turbo87 requested a review from LawnGnome June 6, 2025 08:49
@eth3lbert
Copy link
Contributor

🙋 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
Copy link
Member Author

Turbo87 commented Jun 6, 2025

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
Copy link
Contributor

🙋 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
Copy link
Member Author

Turbo87 commented Jun 6, 2025

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

yeah, we should probably implement that 👍

Some(_) => EndpointScope::PublishUpdate,
None => EndpointScope::PublishNew,
};
let trustpub_token = req
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I might still like a small explanatory comment here along the lines of:

Suggested change
let trustpub_token = req
// Trusted publishing tokens are distinguished from regular crates.io API tokens because they
// use the Bearer auth scheme, so we look for that specific prefix.
let trustpub_token = req

But if you think that's unnecessary, that's not a blocker.

.transpose()
.map_err(|_| forbidden("Invalid authentication token"))?;

let auth = if let Some(trustpub_token) = trustpub_token {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is definitely clearer than before, so 👍.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-backend ⚙️ C-enhancement ✨ Category: Adding new behavior or a change to the way an existing feature works
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants