Sync crates.io Trusted Publishing configs

[Kobzol]

This PR adds support for synchronizing Trusted Publishing configurations for crates published from repositories managed by team.

Currently, it works like this:

• For each crate configured in team, it lists the existing configs.
• If it finds a matching config, nothing is created.
• All non-matching configs will be deleted.
• If a matching config was not found, a new config will be created.

Some additional notes:

• It does not yet do anything with crate owners, that can be done as a follow-up step, now that we have a crates.io API client set up.
• We will not be able to remove a publishing config if someone removes a crate config from the team DB, because the crates.io API does not currently have a way of listing trusted publishing configs for an API token, without knowing the corresponding crate name.
• At most one trusted publishing configuration can be configured per crate (not repo). This both simplifies the implementation, and in general is what we should aim to have, for added security. This is not a limitation of crates.io, but rather a self-imposed requirement of the team DB that I think makes sense.

I already configured this to run on CI, although we do not have the crates.io token configured for dry-run, that might be nice to add (but I don't think that crates.io allows creating read-only tokens, so we would have to do the dry-runs with a full token).

[rustbot]

rust_team_data/src/v1.rs has been modified, it is used (as a git dependency) by multiple sub-projects like triagebot, the www.rust-lang.org website and others.

If you are changing the data structures, please make sure that the changes are not going to break serde deserialization (adding a field is fine; removing or renaming a field isn't).

If you must do a breaking change to the format, make sure to coordinate it with all the users of the rust_team_data crate.

cc @Urgau

[Kobzol]

Actually, given that we might want to have a first-class support for crates in team DB (rust-lang/infra-team#204 (comment)), I will refactor the schema slightly to make it more future-compatible.

[Turbo87]

• Only one trusted publishing configuration can be configured per crate (not repo)

might be worth mentioning that this is a restriction on the team repo side. crates.io does support having multiple trustpub configs :)

[github-actions]

Dry-run check results

[WARN  sync_team] sync-team is running in dry mode, no changes will be applied.
[INFO  sync_team] synchronizing github

[pietroalbini]

Code looks good, left some general feedback.

[pietroalbini]

Nit: I'd call it crates-io-publishing, if in the future we need to integrate with other ecosystems.

[pietroalbini]

I would personally enforce on the sync-team side that an environment is always configured when publishing. I don't see any case when we would want all workflows on a repository to publish crates.

[Kobzol]

This might make it a bit harder to deploy TP though, as creating an environment will require an infra-admin for each repo? Or are they auto-created if you just specify them in the YML workflow file? 🤔

[pietroalbini]

They are not auto-created :(

[pietroalbini]

Only people with maintain+ access on a repo can create environments. We'd need a way to let people create environments without infra-admins involvement. Also, migrating all environments to be managed by the team repo might not be trivial, as a lot of environments nowadays are created by Terraform.

[Kobzol]

Ah, I see, this answers my question above. So what would you prefer? Make environments optional for now? Or make them required and involve infra admins in their creation?

[pietroalbini]

I think it would be better now to require them, and eventually integrate them in the team repo.

[ehuss]

What do environments do in this case? Why would they be required?

[Kobzol]

Environments can be used to ensure that the publish happens only from a specific branch or workflow job. That is useful to ensure that unexpected parts of CI (e.g. those that execute untrusted code at build time) are not allowed to publish.

[Mark-Simulacrum]

Only one trusted publishing configuration can be configured per crate (not repo).

Is this zero or one? It would be nice to have a good way to remove those configs (e.g., if we rename a repo or move it out of rust-lang org), otherwise I worry we'd forget and leave behind a possible future risk.

Or does crates.io attach them to some GitHub repo id despite the naming convention? I don't think that's a thing....

[Kobzol]

It should have said "at most one", I clarified it in the PR description.

Before the endpoint for enumerating TP configs is implemented, I don't think that we can reliably remove all stale configs, right?

The TP configs are attached to a repository name (org/name).

[Kobzol]

Changed to make environment mandatory and expand the set of TPs into a set of crates in the v1 API.