Summary
Enable npm provenance for published
releases of @libredb/libredb, so every published version carries a signed, verifiable attestation
linking the tarball to the exact source commit and the GitHub Actions workflow that built it.
Why
Provenance is a supply-chain integrity signal. With it enabled:
- npm shows a provenance badge on the package page.
- Consumers can run
npm audit signatures to cryptographically verify that the published tarball was
built from this repository, at a specific commit, by our publish.yml workflow — not tampered with
or published from an unknown machine.
This is consistent with the project's reliability and honesty stance and complements the existing
supply-chain hardening (SHA-pinned actions, least-privilege workflow tokens, the full bun run gate
before publish).
Provenance was intentionally deferred while the repository was private, because it requires a public
repository. That precondition is now met (the repo is public and the package is published from GitHub
Actions), and publish.yml already carries a placeholder note for this work.
Current state
.github/workflows/publish.yml publishes without provenance:
permissions:
contents: read
# ...
- run: npm publish --access public
env:
NODE_AUTH_TOKEN: ${{ secrets.NPMJS_TOKEN }}
0.0.4 (the first release published from the public repo) went out without provenance.
Proposed change
- Grant the publish job an OIDC token:
permissions:
contents: read
id-token: write
- Add the
--provenance flag to the publish step:
- run: npm publish --access public --provenance
env:
NODE_AUTH_TOKEN: ${{ secrets.NPMJS_TOKEN }}
(Alternatively, set "provenance": true under publishConfig in package.json; the CLI flag is
preferred here so the behavior is explicit in the workflow.)
Also update the placeholder comment in publish.yml to state that provenance is now enabled.
Preconditions
Acceptance criteria
Notes
- Provenance applies from the version it is first enabled on; already-published versions (
0.0.3,
0.0.4) will not retroactively gain it.
- No new secret is required. Provenance uses the workflow's OIDC identity;
NPMJS_TOKEN still
authenticates the publish itself.
References
Summary
Enable npm provenance for published
releases of
@libredb/libredb, so every published version carries a signed, verifiable attestationlinking the tarball to the exact source commit and the GitHub Actions workflow that built it.
Why
Provenance is a supply-chain integrity signal. With it enabled:
npm audit signaturesto cryptographically verify that the published tarball wasbuilt from this repository, at a specific commit, by our
publish.ymlworkflow — not tampered withor published from an unknown machine.
This is consistent with the project's reliability and honesty stance and complements the existing
supply-chain hardening (SHA-pinned actions, least-privilege workflow tokens, the full
bun run gatebefore publish).
Provenance was intentionally deferred while the repository was private, because it requires a public
repository. That precondition is now met (the repo is public and the package is published from GitHub
Actions), and
publish.ymlalready carries a placeholder note for this work.Current state
.github/workflows/publish.ymlpublishes without provenance:0.0.4(the first release published from the public repo) went out without provenance.Proposed change
--provenanceflag to the publish step:(Alternatively, set
"provenance": trueunderpublishConfiginpackage.json; the CLI flag ispreferred here so the behavior is explicit in the workflow.)
Also update the placeholder comment in
publish.ymlto state that provenance is now enabled.Preconditions
publish.yml)repositoryfield set inpackage.json(provenance links to it)setup-nodeships npm 10+)Acceptance criteria
publish.ymladdsid-token: writeand--provenance.0.0.5) publishes successfully with provenance.npm audit signaturesreports a valid provenance attestation for the new version.publish.ymlis updated.Notes
0.0.3,0.0.4) will not retroactively gain it.NPMJS_TOKENstillauthenticates the publish itself.
References
id-token: write):https://docs.github.com/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect