Initial implementation of GitLab OIDC trusted publisher

[facutuesca]

Description

This PR includes the initial implementation of the GitLab trusted publisher. It's mostly based on the existing GitHub implementation, with a few modifications (mentioned below). Unit tests have been included, and a separate PR for the docs is available here. This is part of Trusted publishing: support for GitLab CI.

The corresponding GitLab feature (along with all the claims provided in the token) is documented here.

Differences with GitHub OIDC

• GitLab uses the term "project" for a repository.
• While GitHub uses the term "username" or "organization" for the org part of github.com/org/repo, GitLab uses the term "namespace". A namespace can be either a username or a group. Groups can be nested, and so for https://gitlab.com/my_org/my_suborg/my_repo, the namespace would be my_org/my_suborg.
• For GitHub publishers, PyPI checks that the username/organization provided exists. For GitLab we don't do this, since namespaces can be private and therefore we can't check if they exist or not. See private groups.
• The above makes this provider less secure that GitHub's, in the sense that it doesn't protect against account resurrection attacks. This is mentioned in the security-model.md doc.
• Environments are case insensitive in GitHub, but are case sensitive in GitLab.
• Workflow files (e.g: workflow.yml) can be anywhere in the GitLab repo. Since the OIDC claims include the path of the workflow relative to the root of the repo, when setting up a GitLab publisher we also ask for this path (as opposed to GitHub, where we only ask for the file name).

TODO

• Once final changes are made, add the screenshots missing to the docs

Screenshot

[woodruffw]

This is great! I did a very fast initial pass; will do a more intensive review after.

[jku]

For GitHub publishers, PyPI checks that the username/organization provided exists. For GitLab we don't do this, since namespaces can be private and therefore we can't check if they exist or not.

I suppose it would not be an impossible requirement to say only public users/orgs can be Trusted Publishers.

This would however have a practical problem when an existing Trusted Publisher decides to make their org private. Dealing with this might not be worth the trouble.

[woodruffw]

I suppose it would not be an impossible requirement to say only public users/orgs can be Trusted Publishers.

Yep, not an impossible requirement, although it would result in an asymmetry vs. GitHub (where any org/repo can publish, whether public or private).

[woodruffw]

Most of the ActiveState provider has landed, so this will probably need a decent bit of deconflicting 🙂

[facutuesca]

Most of the ActiveState provider has landed, so this will probably need a decent bit of deconflicting 🙂

Fixed!

[di]

For GitLab we don't do this, since namespaces can be private and therefore we can't check if they exist or not.

Am I correct in assuming that we can do this for public namespaces? If so, we should probably attempt to do this, determine if the namespace is public or not, and verify this only for public namespaces.

[woodruffw]

Am I correct in assuming that we can do this for public namespaces? If so, we should probably attempt to do this, determine if the namespace is public or not, and verify this only for public namespaces.

Yeah, I think so (@facutuesca can confirm) -- we should be able to do this for public namespaces.

[woodruffw]

We could also do this in a TOFU-ish manner for private namespaces, since the OIDC claim set includes the namespace_id: when the namespace is a private one, we can populate the ID on first sight from the claim set.

(I'm not sure if this is worth doing, however, since it complicates the relationship between the publisher model and token consumption.)

[di]

Overall LGTM, just some minor comments.

[di]

@facutuesca You'll need to re-run make translations to resolve the merge conflicts here.