npm

npm provenance is now generally available.

npm packages built on a supported cloud CI/CD system can publish with provenance. Today this includes GitHub Actions and GitLab CI/CD.

Publishing with provenance verifiably links the package back to its source repository and build instructions. Provenance is restricted to public packages and public source repositories only.

npm will check the linked source commit and repository when you view a package's provenance information on npmjs.com. If the linked source commit or repository cannot be found, an error displays at the top of the page and alongside the provenance information to let you know that provenance for this package can no longer be established. This can happen when a repository is deleted or made private.

Once published, packages display provenance on the registry website:

For more information, see generating provenance.

Starting today, publishing with provenance is restricted to public source repositories only. Private source repositories are no longer supported for use with provenance for public packages.

As announced on July 11, 2023: npm will verify the linked source commit and repository when users view a package's provenance information on npmjs.com. If the linked source commit or repository cannot be found, an error will be displayed. This can occur if a repository is deleted or if it is made private.

Read more about viewing npm provenance and publishing with provenance.

npm will now check the linked source commit and repository when you view a package's provenance information on npmjs.com. If the linked source commit or repository cannot be found, an error displays at the top of the page and alongside the provenance information to let you know that provenance for this package can no longer be established. This can happen when a repository is deleted or made private.

Note: In future releases, publishing a public package with provenance from a private source repository will not be allowed.

Read more about viewing npm provenance and publishing with provenance.

Today we are making further improvements to granular access tokens in npm.

Highlights of this update are

• Custom Expiration Times: You can now create granular access tokens with custom expiration times, allowing for durations that span multiple years.
• Increased Token Limit: We have expanded the maximum limit for granular access tokens creation to 1000. This enables maintainers with a large amount of packages to secure their publishing workflows more efficiently.

We recommend using granular access tokens with least privileges (for example one token per package) for automating your publishing and org management activities.

Read more about creating a granular access tokens here.

In July 2022 the public npm registry migrated away from the existing PGP signatures to a new ECDSA signatures for signature verification.

As of May 2nd 2023, npm packages are no longer signed with PGP based registry signatures. The public key hosted on Keybase will expire.

Read more about registry signatures.

npm packages built on a cloud CI/CD system (like GitHub Actions) can now publish with provenance, meaning the package has verifiable links back to its source code and build instructions.

The cloud CI/CD system securely communicates this information by sending provenance information in a signed OIDC JWT to Sigstore's public-good servers, which returns a signing certificate that is sent to the registry along with your built package.

Here's an example of how to do a build with provenance in a GitHub Actions workflow:

name: Publish Package to npmjs
on:
 release:
   types: [created]
jobs:
 build:
   runs-on: ubuntu-latest
   permissions:
     contents: read
     id-token: write
   steps:
     - uses: actions/checkout@v3
     - uses: actions/setup-node@v3
       with:
         node-version: '18.x'
         registry-url: 'https://registry.npmjs.org'
     - run: npm install -g npm
     - run: npm ci
     - run: npm publish --provenance --access public
       env:
         NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

Once published, packages display provenance on the registry website:

Dependencies with provenance can also be verified from the command line with npm audit signatures.

For more information, see generating provenance.

Today we are making the granular access token feature on npm generally available.

Granular access token, allows you to:

• Restrict token access to specific packages and/or scopes
• Grant tokens access to specific organizations for org and user management
• Set a token expiration date
• Limit token access based on IP address ranges
• Select between read and/or write access for the token

We recommend using granular access tokens with least privileges for automating your publishing and org management activities. You can allow your package to be published without 2FA using granular access tokens from your trusted CI/CD systems. Additionally, you can also configure your package to require 2FA when publishing from a local machine to defend against account hijacking.

Read more about creating a granular access token here.