The Eclipse Foundation’s Open VSX extension registry added Trusted Publishing so publishers using GitHub Actions can replace a stored personal access token with short-lived credentials: a CI workflow presents a signed identity token, the registry checks it against a registration naming the owner, repository and workflow file, and returns a publishing token that lasts about five minutes and works for one extension only. The model follows OpenSSF’s “Trusted Publishers for All Package Repositories” guidance already used by PyPI, npm, RubyGems, NuGet, crates.io and pub.dev, and requires a signed Publisher Agreement, a verified namespace owned by the registrant and an extension with an existing active version, since the first publication still needs a PAT. Registrations match immutable numeric repository and owner IDs while the workflow filename is matched by name, are not tied to a branch or tag so pinning a deployment environment and reviewers is advised, allow only one trusted publisher per extension, and are deleted if their creator stops being a namespace owner. GitLab and self-hosted providers are planned, and the post stresses that whoever can change or run the workflow can still publish, moving the security burden to branch protection, workflow review and environment approvals.
Trusted Publishing on Open VSX
The Eclipse Foundation's Open VSX extension registry added Trusted Publishing so publishers using GitHub Actions can replace a stored personal access token with short-lived credentials: a CI workflow presents a signed identity token, the registry checks it against a registration naming the owner, repository and workflow file, and returns a publishing token that lasts about five minutes and works for one extension only. The model follows OpenSSF's "Trusted Publishers for All Package Repositories" guidance already used by PyPI, npm, RubyGems, NuGet, crates.io and pub.dev, and requires a signed Publisher Agreement, a verified namespace owned by the registrant and an extension with an existing active version, since the first publication still needs a PAT. Registrations match immutable numeric repository and owner IDs while the workflow filename is matched by name, are not tied to a branch or tag so pinning a deployment environment and reviewers is advised, allow only one trusted publisher per extension, and are deleted if their creator stops being a namespace owner. GitLab and self-hosted providers are planned, and the post stresses that whoever can change or run the workflow can still publish, moving the security burden to branch protection, workflow review and environment approvals.
Source: Eclipse