Trusted Publishing support for Semaphore CI

[cchristous]

Request

It would be great to add Semaphore CI as a Trusted Publishing
provider, alongside the existing GitHub Actions and GitLab CI/CD support.

Semaphore issues OIDC tokens to jobs natively (the SEMAPHORE_OIDC_TOKEN env var), with a
standard discovery document and JWKS endpoint, so the pieces needed for crates.io to verify a
token are already in place:

• Discovery: https://<org>.semaphoreci.com/.well-known/openid-configuration
• JWKS: https://<org>.semaphoreci.com/.well-known/jwts
• Docs: https://docs.semaphore.io/using-semaphore/openid and https://docs.semaphore.io/reference/openid

The one thing that's different from the existing providers (issuer model)

I want to flag this up front, because it's the crux and it's where Semaphore differs from
GitHub Actions and GitLab.com:

Semaphore's OIDC issuer is per-organization, not a single shared issuer. The iss claim
is https://<org>.semaphoreci.com (the org's URL), and aud defaults to that same org URL.
That's unlike GitHub Actions (one shared issuer token.actions.githubusercontent.com for
everyone) or GitLab.com (gitlab.com), where a single issuer serves all users and the claims
differentiate them.

So a Semaphore provider needs the issuer to be derived from the trusted-publisher config
rather than a compile-time constant — e.g. the config stores the organization, and the
expected issuer is https://{organization}.semaphoreci.com.

Important scoping: this is not the same as the generic "configurable arbitrary OIDC
issuer" request (#13155, closed not-planned). To keep the threat model tight, this should be
restricted to the vetted Semaphore SaaS apex domain *.semaphoreci.com only — the issuer
hostname is validated against that apex, exactly the way GitLab.com is a single vetted domain.
Self-hosted Semaphore instances (arbitrary domains) would be out of scope, consistent with
crates.io currently supporting GitLab.com but not self-hosted GitLab.

Proposed config shape

Mirroring the existing GitLab provider, plus a derived issuer:

Provider: Semaphore
  organization   ->  used to derive issuer: https://{organization}.semaphoreci.com
                     (validated: host must be a subdomain of semaphoreci.com)
  project        ->  matched against the token's project claim
  repository     ->  matched against the token's repository claim
  ref / branch   ->  matched against the token's git-ref claim

Token claims available for matching (per Semaphore's OIDC reference): the sub is a
combination of org, project, repository, and git reference; there's also a compact sub127
claim (kept under 127 chars) for consumers with size limits.

Audience

Semaphore's default aud is the org URL, but Semaphore has in-flight work to let a job mint a
token with a custom audience (semaphoreio/semaphore#1008),
so the token can carry whatever aud crates.io requires for the exchange. Happy to align on
the expected audience value.

Why it matters

• Adds another CI platform that can publish with short-lived OIDC tokens instead of
  long-lived crates.io API tokens.
• Parity with PyPI/npm, which are moving in the same direction.
• The per-org-issuer pattern here (issuer derived from config, validated against a vetted
  apex) may also be a useful reference for any future forge/provider that assigns a
  per-tenant issuer rather than a single shared one.

Happy to help with details on Semaphore's token format, or to test against a real Semaphore
org if that's useful.