Why did package-lock.json change the integrity hash from sha1 to sha512?

Question

I just generated a new npm lockfile, package-lock.json, as part of my typical workflow. But I noticed that this time all of the integrity hashes have been changed from sha1 to sha512. What is happening here?

"chalk": {
    "version": "2.0.1",
    "resolved": "https://registry.npmjs.org/chalk/-/chalk-2.0.1.tgz",
-   "integrity": "sha1-ce5R+nvkyuwaY4OffmgtgTLTDK8=",
+   "integrity": "sha512-lyuxPGr/Wfhrlem2CL/UcnUc1zcqKAImBDzukY7Y5F/yQiNdko6+fRLevlw1HgMySw7f611UIY408EtxRSoK3Q==",
    […]
}

Primavera

It's an issue with npm: github.com/npm/npm/issues/17749 – Prodrome

The issue referenced above has been closed and now an article is created to instruct how to solve this problem: npm.community/t/shasum-check-or-integrity-eintegrity-errors/153 – Hardhearted

The above npm.community link is a 404 now. – Anzovin

Answer 1

From what I can see, npm changed the integrity checksum from sha1 to sha512.

If your git changes are going from sha1 to sha512, you should do that update once and it will be good after that.

If someone else working with the codebase and sees a git change from sha512 down to sha1 (which is the issue I was having) you can fix it by running the following:

Discard the changes in git for package-lock.json

npm i -g npm
rm -rf node_modules/
npm i

This will update npm and reinstall all of your packages so that the new checksum (sha512) is present.

Renfrow

Is there a reason to use sha512 over sha1? My computer is currently the one changing to sha1 for our environment. – Karp

@Karp I'm going to guess less possibility of 'faking' the hash with a collision? – Ecumenicist

This wasn't sufficient in my case. In addition to delete the node_modules folder, I needed npm cache clear --force too. – Giff

@Karp "The basic difference between SHA1 and SHA512 is the length of hash values generated by both algorithms – SHA1 has a 160-bit hash value while SHA512 has a 512-bit hash value. Therefore, making SHA512 a much more secure algorithm." (In case of node modules, the probability of a collision is much lower.) – Justiciar

Warning: If your node version is no longer supported by the latest version of npm, the first command in this answer will just break your npm and you will have to reinstall using another package manager, or download from nodejs.org. – Anzovin

Answer 2

Building on what Dave answered. The fix i found was to do the following:

npm i -g npm

cd {working directory}
rm -rf node_modules/
rm package-lock.json
npm cache clear --force
npm i

We did this for all our developers at the same time and this stopped the sha-512 vs sha-1 issue which was causing frustrating merge conflicts.

Locus

You should never remove you package-lock.json file. https://mcmap.net/q/56118/-deleting-package-lock-json-to-resolve-conflicts-quickly – Saito

I needed to revert rather than remove package-lock.json. – Scalawag

This worked for me. I agree with @ThdK, you should not need to remove package-lock.json. Simply revert it to a correct state, then follow the steps in this answer (without removing package-lock) – Heida

Answer 3

See also https://github.com/npm/npm/issues/17749 which although claims the issue is 'fixed', it isn't. Removing node_modules is a workaround.

There may be a relationship with operating systems. We're hitting this right now with developers on Linux and Windows platforms.

Yeld

We moved to yarn in the end. – Yeld

Every NPM problem seemingly resolved by moving to Yarn – Kilar

Answer 4

I'm working in big team. Forcing every developer to force clean npm cache is difficult and not reliable. Also, this doesn't help every time. So, for anyone who still facing this npm issue (same as me) and nothing else helps – try this git based tool I've built recently: https://github.com/kopach/lockfix. It reverts sha512 -> sha1 integrity changes of npm's lock files. If you add this to your postshrinkwrap script of package.json - you should eventually get all integrity properties set to sha512 and have lock file consistent.

npm install --save-dev lockfix

"scripts": {
    "postshrinkwrap": "lockfix",
},

Neoteny

curious, can that be run via npx instead? – Rickrack

@GeorgeWL, yes, check README for details github.com/kopach/lockfix#manually-from-terminal – Neoteny

Answer 5

As @Daniel Cumings I also had to remove the package-lock.json to get rid of the sha1 hashes. Here's the Windows CLI commands for reference, which does the same as Daniel's script:

npm i -g npm
rd /s /q "node_modules"
del package-lock.json
npm cache clear --force
npm i

Sledgehammer

Answer 6

If you're using npm v5 or later, and you're seeing the integrity hashes changing from sha512 back to sha1, one way to remedy that without removing your package-lock.json is to do the following:

1. Remove all the sha1 integrity hashes from your package-lock.json (do not remove your package-lock.json); for example:

   diff --git a/package-lock.json b/package-lock.json
   index 6374e258..05f77ec8 100644
   --- a/package-lock.json
   +++ b/package-lock.json
   @@ -56,12 +56,10 @@
        "@babel/core": {
          "version": "7.9.6",
          "resolved": "https://registry.npmjs.org/@babel/core/-/core-7.9.6.tgz",
   -      "integrity": "sha1-X+QF1VU04G078GD4anmTXNpfZhU="
        },
        "@babel/parser": {
          "version": "7.9.6",
          "resolved": "https://registry.npmjs.org/npm-adobe-release/@babel/traverse/-/traverse-7.9.6.tgz",
   -      "integrity": "sha1-fGzlDyLGPvCJNpHXPZrCdGz7QSY="
        },
   

2. Remove your node_modules: rm -rf node_modules
3. Clear the npm cache: npm cache clean --force
4. Install the packages: npm install

This should result in your package-lock.json updated with the sha512 integrity hashes.

Gisser

Package-lock states this in big letters: This is an auto-generated file, NEVER modify it manually – Rickrack

@Rickrack - the proposed solution is a workaround for the integrity SHA checksums only, and is not intended in the sense to modify other aspects of the package-lock.json file. – Gisser

that doesn't change the fact that one should NEVER manually edit the package-lock – Rickrack

Answer 7

You can resolve this issue by doing the below following changes:

1. Ensure npm version: 7.x or above
2. Create a .npmrc file

// .npmrc
lockfile-version=3

3. Remove your node_modules: rm -rf node_modules/
4. Remove existing package-lock.json: rm package-lock.json
5. Install npm packages: npm install

You can check the integration hash:

$ grep -o 'sha1' package-lock.json | wc -l

Outlet

Answer 8

This most likely happened because you changed the node version you're using. Newer version of npm use hash512.

In my case I work in a shared project and what happened is I ran a FRESH npm i with a newer version of npm which caused my package-lock file to be changed to use hash512. After that, I refreshed my branch, i.e git reset --hard && git pull, which brought to me a package-lock file with SHA1 checksums. Because I still had my node_modules installed with a newer version of npm right after doing git pull I ran npm i which changed my package-lock file to use hash512.

The tl;dr is:

1. Make sure you're using the correct node version for the project, prefer using nvm use
2. rm -Rf node_modules && npm i (you MUST do rm -Rf node_modules, otherwise you will keep getting package-lock changes)

This should keep your project consistent

Handbreadth

Answer 9

Works on node 14

rm -rf node_modules/
npm cache clean --force
sed -i '' 's/"sha1-.*"/""/g' package-lock.json
npm i

rm -rf node_modules/ - remove node_modules from project to remove persisted packages with sha1 integrities

npm cache clean --force - remove cached modules and integrities

sed -i '' 's/"sha1-.*"/""/g' package-lock.json - replace all sha1 integrities by empty strings

npm i - to update integrities in package-lock.json, node_modules and npm cache.

Result:

• "npm i" will always install packages with sha512 integrity.
• Even if one of the developers does not follow this instruction and commits sha-1 - reinstalling (npm i) on your machine will return sha512 back.

Domini

Answer 10

In my case npm -g i npm was not enough, I had to modify PATH to point new npm at begining.

To check it without modification try /usr/local/bin/npm i instead of npm i.

Grous

Answer 11

Further building on previous comments and suggestions, for me I needed to wipe the existing node_modules folder, the cache, and then grab the sha512 package-lock.json file from git (which was committed from another computer), and finally do an npm i. Something like this:

npm i -g npm
rm -rf node_modules/
npm cache clear --force
git reset --hard
npm i

After this package-lock.json used sha512 and other changes stabilized.

Joaniejoann

is git reset --hard really needed in this case? – Afterburner