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.

We have streamlined the npm password reset flow to simplify and secure the process of resetting lost passwords for you npm account.

For more information about creating a strong password, see "Creating a strong password".

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

PGP based registry signatures will be deprecated on March 31st 2023. This means no new packages will be signed with PGP keys from this date onwards and the public key hosted on Keybase will expire.

Read more about registry signatures.

We have streamlined our account recovery flow to help us verify your identity in the instance you lose access to your two-factor authentication (2FA) device and get locked out of your npm account.

If you lose access to your 2FA device and your recovery codes, you can now sign in to your npm account using your username and password and then request an account recovery. You will be asked to fill the form as shown below. We recommend you provide as much information as possible when requesting an account recovery.

Read more about how you can recover your 2FA enabled accounts here.

For accounts with 2FA, linking your GitHub account and Twitter account in your profile settings will help verify your identity quicker.

Note: The new account recovery flow tries to gather and map information about your identity such that our support team can address your request sooner. Since there is a manual review in place, this recovery process will take few days to complete. We recommend our users generate and keep a copy of their recovery code to be used as the primary recovery option and avoid getting locked out of your account for a prolonged period of time.