Raised by CodeRabbit on #9 against release-record.yml, and deferred from that PR on purpose: the
same pattern is in release.yml, which #9 does not touch. Hardening one workflow and not the other
leaves the exposure in place while looking like it was handled, so the two should move together.
What to change
Both .github/workflows/release.yml and .github/workflows/release-record.yml pass cache: npm
to actions/setup-node. Both jobs hold id-token: write, mint an npm publishing credential from
their OIDC identity, and run npm ci — which executes dependency lifecycle scripts — before
publishing.
Drop cache: npm and set package-manager-cache: false in both.
Why
The GitHub Actions cache is a cross-job channel into a job that has a publishing credential. npm ci does verify integrity hashes against the lockfile, so this is defence in depth rather than a
live hole — but a release build is exactly where a clean, reproducible environment is worth more
than the seconds the cache saves. actions/setup-node's own advanced-usage docs recommend
disabling it for privileged workflows.
Note the repository has no packageManager or devEngines.packageManager field, so the automatic
caching path is not in play; cache: npm is set explicitly and removing it is sufficient. Setting
package-manager-cache: false as well keeps it that way if such a field is ever added.
Nothing else in either workflow needs to move — registry-url is deliberately absent in both, for
the OIDC reason each file already documents.
Raised by CodeRabbit on #9 against
release-record.yml, and deferred from that PR on purpose: thesame pattern is in
release.yml, which #9 does not touch. Hardening one workflow and not the otherleaves the exposure in place while looking like it was handled, so the two should move together.
What to change
Both
.github/workflows/release.ymland.github/workflows/release-record.ymlpasscache: npmto
actions/setup-node. Both jobs holdid-token: write, mint an npm publishing credential fromtheir OIDC identity, and run
npm ci— which executes dependency lifecycle scripts — beforepublishing.
Drop
cache: npmand setpackage-manager-cache: falsein both.Why
The GitHub Actions cache is a cross-job channel into a job that has a publishing credential.
npm cidoes verify integrity hashes against the lockfile, so this is defence in depth rather than alive hole — but a release build is exactly where a clean, reproducible environment is worth more
than the seconds the cache saves.
actions/setup-node's own advanced-usage docs recommenddisabling it for privileged workflows.
Note the repository has no
packageManagerordevEngines.packageManagerfield, so the automaticcaching path is not in play;
cache: npmis set explicitly and removing it is sufficient. Settingpackage-manager-cache: falseas well keeps it that way if such a field is ever added.Nothing else in either workflow needs to move —
registry-urlis deliberately absent in both, forthe OIDC reason each file already documents.