[pull] latest from npm:latest - #139
Merged
Merged
Conversation
This pull request adds support for CircleCI as a provider of OpenID
Connect (OIDC) tokens in CI environments, alongside existing support for
GitHub Actions and GitLab. The implementation includes both code changes
to detect and handle CircleCI OIDC tokens and new tests to ensure
correct behavior.
## Usage
In your `.circleci/config.yml`:
```yaml
version: 2.1
jobs:
publish:
docker:
- image: cimg/node:lts
steps:
- checkout
- run:
name: Publish to npm
command: |
NPM_AUDIENCE="npm:$(npm config get registry | sed 's|https\?://||;s|/$||')"
NPM_ID_TOKEN=$(circleci run oidc get --claims "{\"aud\": \"$NPM_AUDIENCE\"}")
npm publish
workflows:
publish:
jobs:
- publish
```
Note: Unlike GitHub Actions and GitLab, CircleCI requires manually
fetching the OIDC token with the correct audience claim using the
`circleci` CLI.This pull request adds support for CircleCI as a trusted provider in the trust command system. The changes introduce a new `circleci` subcommand, implement its logic for validating and processing CircleCI-specific trust relationships, and update documentation and tests to reflect the new functionality.
Fixes#8892 Older packages on the registry use the deprecated `licenses` array (`"licenses": [{"type": "MIT", ...}]`) instead of the singular `license` string. `npm sbom` only checked for `license`, so these packages all showed up as `NOASSERTION`. This checks for the `licenses` array as a fallback in both the SPDX and CycloneDX codepaths. When there are multiple entries they're joined with ` OR `. Also noticed the CycloneDX expression branch was referencing `node.package.license` directly instead of the already-computed variable, which would break for these legacy packages. Fixed that too.
) Continuing the `install-strategy=linked` fixes from #8996. While testing on the [Gutenberg monorepo](WordPress/gutenberg#75814), `esbuild` installs fail because its postinstall script runs twice in parallel against the same store directory. ## Summary With `install-strategy=linked`, postinstall scripts run twice for every store package — once for the store entry and once for its symlink. For packages like `esbuild` whose postinstall modifies files in-place (`fs.linkSync` to replace the JS wrapper with a native binary), this race condition corrupts the install. ## Root cause In `rebuild.js`, `#runScripts` destructures `isStoreLink` from `node.target` (the store entry) to decide whether to skip a node. But `isStoreLink` is a property of the link node itself (`node`), not its target. Store entries don't have `isStoreLink`, so it's always `undefined` and the guard never triggers. Both the store entry and the store link run scripts against the same directory in parallel. ## Changes - Fixed the skip condition in `rebuild.js` `#runScripts` to use `node.isLink && node.target?.isInStore` instead of reading `isStoreLink` from `node.target`. This correctly skips store links (symlinks pointing to store entries) while still allowing workspace links and store entries themselves to run scripts. - Added a regression test that verifies postinstall scripts run exactly once for store packages. ## References Fixes#9012
npm audit signatures fails when a registry only uses keyless (Sigstore/Fulcio) attestations and doesn't provide registry signing keys. The[ auditedWithKeysCount guard in verify-signatures.js ](https://github.com/npm/cli/blob/latest/lib/utils/verify-signatures.js#L48) treats any registry without keys as unsupported, even though keyless attestations don't need registry keys at all -- the signing certificate is embedded directly in the bundle and verified through Sigstore's TUF root of trust. This updates the check to also accept verified keyless attestations as a valid audit result, so registries that exclusively use Fulcio-based signing (like Chainguard) work correctly with npm audit signatures. Before this change: npm error found no dependencies to audit that were installed from a supported registry After: audited 1 package in 1s 1 package has a verified attestation This change works together with the corresponding pacote fixes ([pacote/pull/454](npm/pacote#454)) ([pacote/pull/452](npm/pacote#452)) which allows keyless attestation bundles to pass the registry key matching check.
LadyK-21
commented
Feb 25, 2026
Owner
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )