💻
What problem are you trying to solve?
Babel is already publishing to npm via OIDC / Trusted Publishing (the npm-release job in .github/workflows/release.yml sets id-token: write and runs in the npm environment), but the published packages do not include npm provenance attestations.
Without provenance, consumers can't cryptographically verify which source repository, commit, and workflow run produced a given @babel/* tarball on the registry. Given Babel's position in the JS ecosystem (it's a build-time dependency of basically everything), this is a meaningful supply-chain gap, and one that's nearly free to close now that Trusted Publishing is already wired up.
Describe the solution you'd like
Enable provenance generation when publishing from CI. Since the OIDC permissions and npm environment are already in place, the change is essentially:
Pass --provenance to the publish command (e.g. yarn release-tool publish --yes --tag next --provenance)
Describe alternatives you've considered
Do nothing. Keep relying purely on Trusted Publishing. This protects the publish credential, but doesn't give downstream users any way to verify the artifact's origin.
Documentation, Adoption, Migration Strategy
No response
💻
What problem are you trying to solve?
Babel is already publishing to npm via OIDC / Trusted Publishing (the
npm-releasejob in.github/workflows/release.ymlsetsid-token: writeand runs in thenpmenvironment), but the published packages do not include npm provenance attestations.Without provenance, consumers can't cryptographically verify which source repository, commit, and workflow run produced a given
@babel/*tarball on the registry. Given Babel's position in the JS ecosystem (it's a build-time dependency of basically everything), this is a meaningful supply-chain gap, and one that's nearly free to close now that Trusted Publishing is already wired up.Describe the solution you'd like
Enable provenance generation when publishing from CI. Since the OIDC permissions and
npmenvironment are already in place, the change is essentially:Pass
--provenanceto the publish command (e.g.yarn release-tool publish --yes --tag next --provenance)Describe alternatives you've considered
Do nothing. Keep relying purely on Trusted Publishing. This protects the publish credential, but doesn't give downstream users any way to verify the artifact's origin.
Documentation, Adoption, Migration Strategy
No response