This repository has been archived by the owner. It is now read-only.

npm WARN registry Unexpected warning for https://registry.npmjs.org/: #17146

Open
tomciopp opened this Issue Jun 12, 2017 · 51 comments

Comments

Projects
None yet
@tomciopp

tomciopp commented Jun 12, 2017

I'm opening this issue because:

  • npm is crashing.
  • npm is producing an incorrect install.
  • npm is doing something I don't understand.
  • Other (see below for feature requests):

What's going wrong?

When I run npm install all of the packages listed in "dependencies" are missing. Can be confirmed when running npm outdated. I suspect this is related to the following error that shows up when I run npm install.

npm WARN registry Unexpected warning for https://registry.npmjs.org/: Miscellaneous Warning EINTEGRITY: sha512-ijDLlyQ7s6x1JgCLur53osjm/UXUYD9+0PbYKrBsYisYXzCxN+HC3mYDNy/dWdmf3AwqwU3CXwDCvsNgGK1S0w== integrity checksum failed when using sha512: wanted sha512-ijDLlyQ7s6x1JgCLur53osjm/UXUYD9+0PbYKrBsYisYXzCxN+HC3mYDNy/dWdmf3AwqwU3CXwDCvsNgGK1S0w== but got sha1-Vx4PGwYEY268DfwhsDObvjE0FxA=. (2069 bytes)

How can the CLI team reproduce the problem?

I'm assuming just run npm install

https://gist.github.com/tomciopp/8851f07a17dd266dcfb34e40fa794a62

supporting information:

  • npm -v prints: 5.0.3
  • node -v prints: v8.1.0
  • npm config get registry prints: https://registry.npmjs.org/
  • Windows, OS X/macOS, or Linux?: OSX
  • Network issues:
    • Geographic location where npm was run: New York
    • I use a proxy to connect to the npm registry.
    • I use a proxy to connect to the web.
    • I use a proxy when downloading Git repos.
    • I access the npm registry via a VPN
    • I don't use a proxy, but have limited or unreliable internet access.
  • Container:
    • I develop using Vagrant on Windows.
    • I develop using Vagrant on OS X or Linux.
    • I develop / deploy using Docker.
    • I deploy to a PaaS (Triton, Heroku).
@jandeu

This comment has been minimized.

jandeu commented Jun 13, 2017

Hi, had the same problem here. It seems it's affecting only npm version 5.x.x. Downgraded to npm@4.6.1 and all packages were installed correctly.

@olange

This comment has been minimized.

olange commented Jun 13, 2017

Update 14.06 (3/3): after deleting NPM cache (with npm cache clear --force) and <project>/node_modules from all target systems (RHEL6, OSX, Windows 8), reinstalling the project modules with npm install --no-shrinkwrap --update-binary and shrinkwrapping afterwards (with npm shrinkwrap), I got an identical npm-shrinkwrap.json in every system, that consistently builds across all of the RHEL/OSX/Windows8 systems and does not report SHA checksum issues anymore. It is beyond my understanding how it solved the issue.

In my issue, the main differences in npm-shrinkwrap.json came from the fsevents module's dependencies, where its embedded modules had their bundled attribute replaced by resolved and integrity attributes. I also had some differences on attributes "dev": true. Sample diff from the npm-shrinkwrap.json:

     "fsevents": {
       "version": "1.1.2",
       "resolved": "https://registry.npmjs.org/fsevents/-/fsevents-1.1.2.tgz",
       "integrity": "sha512-Sn44E5wQW4bTHXvQmvSHwqbuiXtduD6Rrjm2ZtUEGbyrig+nUH3t/QD4M4/ZXViY556TBpRgZkHLDx3JxPwxiw==",
       "optional": true,
        "dependencies": {
          "abbrev": {
            "version": "1.1.0",
 -          "bundled": true,
 +          "resolved": "https://registry.npmjs.org/abbrev/-/abbrev-1.1.0.tgz",
 +          "integrity": "sha1-0FVMIlZjbi9W58LlrRg/hZQo2B8=",
            "optional": true
          },
          …

Hope this helps… Sorry for the noise, if my issue was not really linked to the one reported.


Update 14.06 (2/3): back to the Mac OSX and Windows 8 systems, with the freshly updated npm-shrinkwrap.json from the RHEL6 system, I get a checksum issue again:

$ npm install
npm WARN registry Unexpected warning for https://registry.npmjs.org/: Miscellaneous Warning EINTEGRITY: sha1-EyfXCZULVY8gTlNSWH/QKQ+Njkg= integrity checksum failed when using sha1: wanted sha1-EyfXCZULVY8gTlNSWH/QKQ+Njkg= but got sha512-mq0x3HCAGGmQyZXviOVe5TRsw37Ijy3D43jCqt/9WVf+onx2dUgW3PosnqCbScAFhRO9DGs8nxoMzU0iiosMqQ==. (68904 bytes)
…

What is quite confusing, is that this EINTEGRITY error message does not indicate which module has a checksum error: it only states the source registry https://registry.npmjs.org/.


Update 14.06 (1/3): solved the issue by deleting npm-shrinkwrap.json, re-running npm install on the RHEL6 system, and then npm shrinkwrap. It updated a few embedded dependencies to their latest versions, plus replaced some SHA1 checksums with SHA512, some other SHA512 with SHA1 checksums, and did not report any SHA checksum mismatch anymore on the RHEL6 system.

Not sure about the root cause and if it relates to this issue – may be you should ignore my comment hereafter. I'm still a bit confused of why the same npm-shrinkwrap.json (already in lockfile@v1 format of NPM v5) worked on Windows 8 and Mac OSX systems, and not the RHEL6 system, all of them running Node v8.0.1 and NPM v5.0.3.


Hello. I encountered the same problem on RHEL6, while trying to build an app that requires jsedn, which itself requires type-component: the later is not installed and the app fails to run. npm install reports following error on Red Hat Enterprise Linux 6:

npm WARN registry Unexpected warning for https://registry.npmjs.org/: Miscellaneous Warning EINTEGRITY: sha1-B5azH412iAB/8Lk6gIjTSqF8D3I= integrity checksum failed when using sha1: wanted sha1-B5azH412iAB/8Lk6gIjTSqF8D3I= but got sha512-h+8+r3MKEhkiVrwdKL8aWs1oc1VvBu33ueshOvS26RsZQ3Amhx/oO3TKe4lApSV9ueY6as8EAh7mtuFjdlhg9Q==. (23462 bytes)

No problem though for the exact same build on Windows 8.

Tried to clean my ~/.npm folder (rm -rf ~/.npm), same issue.

@JonathonRichardson

This comment has been minimized.

JonathonRichardson commented Jun 14, 2017

I hit this problem while experimenting with ProGet npm registries, which allowed me to publish the same package version multiple times (thus changing the hash). I solved it by deleting the package-lock.json (which may be named npm-shrinkwrap.json as in @olange's case), since I lock my packages in package.json anyway. npm install will then just recreate this when it runs again. Running npm cache clear --force won't hurt, but I don't think it's necessary.

I'm no expert, but I'm curious which package caused this. Can you look in your package-lock.json to see what package is associated with that integrity hash (sha1-Vx4PGwYEY268DfwhsDObvjE0FxA=)? It looks like the hashing method changed from SHA1 to SHA512, but I'm not sure how the method is determined.

@olange

This comment has been minimized.

olange commented Jun 15, 2017

@JonathonRichardson Hi Jonathon, the first packages with which I encountered these SHA1/SHA512 checksum warnings is type-component, and then a few others.

But the issue does not seem to be related to the checksums on the registry, rather with the way NPM calculates these checksums on different platforms.

I realized that depending on which system I was, npm shrinkwrap would produce SHA512 or SHA1 checksums, as well as it would change the placement of packages that are embedded in some other packages, are add or remove the "dev": true and "bundled": true attributes.

So, for me, it is either a platform dependent issue or, IMO more likely, what was available in the local cache on the different systems.

@nukeop

This comment has been minimized.

nukeop commented Jun 19, 2017

This is still broken. It fucks up checksums, and electron won't install correctly with npm version 5, you need to downgrade to 4 for it to work.

@onigoetz

This comment has been minimized.

onigoetz commented Jun 21, 2017

I also have a similar issue,

[ERROR] npm ERR! code EINTEGRITY
[ERROR] npm ERR! sha1-gswqb03PNvrPDHp5RoV7/2KCisc= integrity checksum failed when using sha1: wanted sha1-gswqb03PNvrPDHp5RoV7/2KCisc= but got sha1-U3cWwHduTPeePtG2IfdljCkRsbE=. (3344 bytes)

It would be pretty cool if it said for which package the checksum failed ... It fetches hundreds of packages and throws this in the middle. not very useful for debugging.

By the way, I run this in a docker image that doesn't have a cache (yet)

@nguyentrucxinh

This comment has been minimized.

nguyentrucxinh commented Jun 23, 2017

rm ./package-lock.json
rm -r ./node_modules
npm cache clear --force

That is the way i resolved this problem

I founded it at #7506 with the comment of @aliaksandr-master

@luciagirasoles

This comment has been minimized.

luciagirasoles commented Jun 23, 2017

@nguyentrucxinh your link is broken....

@nguyentrucxinh

This comment has been minimized.

nguyentrucxinh commented Jun 23, 2017

@luciagirasoles i fixed it, thank you!

@gigmaps

This comment has been minimized.

gigmaps commented Jun 29, 2017

@nguyentrucxinh shouldn't that 2nd line be rm -r ./node_modules ?

...since rm ./node_modules won't work on a non-empty directory
(as per https://askubuntu.com/a/217906 or similar)

@nyuszika7h

This comment has been minimized.

nyuszika7h commented Jul 10, 2017

...since rm ./node_modules won't work on a non-empty directory

It won't work on any directory, empty or not.

@gaurav-chandra

This comment has been minimized.

gaurav-chandra commented Jul 29, 2017

@nguyentrucxinh solution worked for me. Thanks.

@lawlietxxl

This comment has been minimized.

lawlietxxl commented Aug 7, 2017

I run into this problem when I'm using a react command: create-react-app, and it turned out as an ERROR. Then I delete all the node modules globally, then reinstall create-react-app, and everything works fine.
os: macos
how to remove all the modules: stackoverflow

@hezhiwebworld

This comment has been minimized.

hezhiwebworld commented Aug 9, 2017

npm ERR! code EINTEGRITY
npm ERR! sha1-+Osa0A3FilUUNjtBylNCgX8L1kY= integrity checksum failed when using
sha1: wanted sha1-+Osa0A3FilUUNjtBylNCgX8L1kY= but got sha1-gDAPSkPbqJMLsAVJA5AS
t+3CSiU=. (97776 bytes)

drag npm4 ,it sill bad

@sergey-morenets

This comment has been minimized.

sergey-morenets commented Aug 22, 2017

npm cache clear --force and npm install --no-shrinkwrap --update-binary resolved this issue for me.

@rhys-e

This comment has been minimized.

rhys-e commented Sep 9, 2017

I don't understand how people are suggesting removing the package-lock.json or npm-shrinkwrap.json is a solution. Yes, you may not get integrity warnings anymore, but you've also removed all the guarantees the lock/shrinkwrap was put in place to give you.

Unless I've missed something, I haven't seen any explanation by anyone as to why these warnings are happening in the first place?

tereg added a commit to FuzzyHatPublishing/isleep that referenced this issue Sep 11, 2017

Remove and reinstall package-lock.json
This is a solution that was effective for others who ran into issues with:
npm ERR! code EINTEGRITY
npm ERR! sha1-gEtYFQQmxo5NomZJDUPsY52VlT0= integrity checksum failed when using sha1: wanted sha1-gEtYFQQmxo5NomZJDUPsY52VlT0= but got sha1-vefnCRPgF/ea/hiJcK2+2MALOFg=. (27877159 bytes)

More info available here:
npm/npm#17146
@JMuhire

This comment has been minimized.

JMuhire commented Dec 27, 2017

Removing the rm package-lock.json file resolved the problem.

@soulne4ny

This comment has been minimized.

soulne4ny commented Jan 27, 2018

rm package-lock.json works, but in my case, it must be removed before every npm invocation.

@DanielRuf

This comment has been minimized.

DanielRuf commented Jan 27, 2018

Well, you just have to clear the npm cache or force reinstall the deps or remove node_modules. A lockfile has a reason (lock to specific versions, shared among all users of the project).

@jwalton

This comment has been minimized.

jwalton commented Feb 3, 2018

I'm seeing this on a travis docker build, where I have a brand new node:8.9.4-alpine container on each build. Sometimes it happens, sometimes it doesn't. Just restarting the build (sometimes) fixes it, with exactly the same package.json and package-lock.json. Something is seriously broken here.

@DanielRuf

This comment has been minimized.

DanielRuf commented Feb 3, 2018

Which npm version is used? It is not happening here anymore. Also this might be a connection / network issue.

@jwalton

This comment has been minimized.

jwalton commented Feb 3, 2018

node:8.9.4-alpine is currently using npm v5.6.0. This happened to three of my travis-ci builds yesterday out of about... 20ish. Two back-to-back, another a few hours previously, with lots of successful builds inbetween.

What sort of connection/network issue did you have in mind? :)

@DanielRuf

This comment has been minimized.

DanielRuf commented Feb 3, 2018

So far all Travis builds with npm 5 do not have this issue, at least in the projects where I contribute to and watch the builds.

@jwalton

This comment has been minimized.

jwalton commented Feb 3, 2018

Are any of your projects on alpine, by any chance? I've run into enough other muslc weirdness in the past 24 hours than I'm perhaps overly suspicious. :P

@DanielRuf

This comment has been minimized.

DanielRuf commented Feb 3, 2018

Not sure but at least some of the docker containers use the Alpine distro afaik.

@jwalton

This comment has been minimized.

jwalton commented Feb 4, 2018

Happened to me twice today. Looking at the build, I notice a bunch of errors about missing files:

npm WARN deprecated CSSselect@0.4.1: the module is now available as 'css-select'
npm WARN deprecated CSSwhat@0.4.7: the module is now available as 'css-what'
npm WARN tar ENOENT: no such file or directory, lstat '/app/node_modules/.staging/moment-timezone-e8916734/data/unpacked'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/mousetrap-d5a23c7b/tests/libs/key-event.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/mousetrap-d5a23c7b/tests/libs/mocha-1.9.0.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/grpc-3f2a182e/deps/grpc/third_party/boringssl/crypto/cipher/test/aes_256_cbc_sha1_tls_tests.txt'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/reduce.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/context.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/chart.js-db360194/dist/Chart.bundle.min.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/schedule.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/catch_filter.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/settle.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/cancel.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/some.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/call_get.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/synchronous_inspection.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/bluebird.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/thenables.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/bind.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/timers.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/async.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/using.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/assert.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/util.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/bluebird-403f485b/js/release/map.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/grpc-66313728/deps/grpc/third_party/boringssl/include/openssl/thread.h'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/grpc-66313728/deps/grpc/third_party/boringssl/include/openssl/tls1.h'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/typescript-2d0ca0bc/lib/typescriptServices.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/lodash-486e720a/_createCaseFirst.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/lodash-486e720a/lodash.min.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/nyc-6e06d2b4/node_modules/handlebars/dist/handlebars.amd.min.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/moment-d30432dd/min/locales.min.js'
npm ERR! code EINTEGRITY
npm ERR! sha1-zgbdGxAS025boTS9QGt2JtTZt8U= integrity checksum failed when using sha1: wanted sha1-zgbdGxAS025boTS9QGt2JtTZt8U= but got sha1-nxrH1ykedriX/msSvvlF56ml8A0=. (48729 bytes)
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/fsevents-a1424645/node_modules/hawk/test/uri.js'
npm WARN tar ENOENT: no such file or directory, open '/app/node_modules/.staging/fsevents-a1424645/node_modules/hawk/test/utils.js'
npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2018-02-04T16_13_01_486Z-debug.log

Different missing files in each run.

@zakkor

This comment has been minimized.

zakkor commented Feb 6, 2018

I fixed this issue by completely removing npm and installing yarn

@DanielRuf

This comment has been minimized.

DanielRuf commented Feb 6, 2018

I fixed this issue by completely removing npm and installing yarn

This is not a fix.

@dantheman999301

This comment has been minimized.

dantheman999301 commented Feb 8, 2018

For me the necessary steps were:

  1. Clear cache on both build slave and local machine.
  2. Get npm and node onto same versions on both machines.
  3. Delete the package-lock.json file.
  4. npm install on the local machine.
  5. Commit and push new package-lock.json

Then it worked.

@peter-mount

This comment has been minimized.

peter-mount commented Feb 9, 2018

I was hit with the same EINTEGRITY error but for me it turned out to be my repo.

I'm using Nexus3 for the local repo & proxy of the main npm repo but it turned out the local metadata got corrupted. Version 1.8.0 was released on Monday (Feb 5) and upgrading it, invalidating the proxy & redeploying affected artefacts in the local repo fixed the problem.

@grantbrown

This comment has been minimized.

grantbrown commented Mar 5, 2018

I'm getting this warning when installing pm2 on an Ubuntu docker image, running on a Fedora host. It's docker, so the install is fresh, and should "just work".

I'm not a frequent node user, and experiences like this don't inspire confidence. Reliably delivering cryptographically verified packages across platforms and architectures seems like a pretty basic task for any package manager...

@Legends

This comment has been minimized.

Legends commented Mar 8, 2018

I have deleted, node_modules folder and packages.json.lock file.
Installed latest yarn.

yarn install <-- no errors ! instead of npm install.

Worked like a charm.

@DanielRuf

This comment has been minimized.

DanielRuf commented Mar 8, 2018

Lol, installing yarn is not a solution.

@ediweissmann

This comment has been minimized.

ediweissmann commented Mar 15, 2018

I've experienced the same thing as grantbrown above. Fresh install, npm --version 5.6.0 and node --version v8.10.0.

Experiences like this don't inspire confidence.

@jakeNiemiec

This comment has been minimized.

jakeNiemiec commented Mar 15, 2018

@ediweissmann 5.4.2 is my goto version for now. Very solid.

@rambardeveloper

This comment has been minimized.

rambardeveloper commented Apr 6, 2018

I only did "npm cache verify" and my problem was solved

@dhunmoon

This comment has been minimized.

dhunmoon commented Apr 15, 2018

@olange Thanks so much so much for the solution it really worked for me.

@franDayz

This comment has been minimized.

franDayz commented May 7, 2018

Downgrading to Node v6.14.2 worked for me

@DanielRuf

This comment has been minimized.

DanielRuf commented May 7, 2018

Downgrading to Node v6.14.2 worked for me

This probably cleared the caches. Try upgrading / downgrading npm.

@TomasRup

This comment has been minimized.

TomasRup commented May 9, 2018

So I have this issue, when package-lock.json is produced with npm@5.8.0, the npm install fails with npm@5.6.0 for SOME packages.

So just try to align the versions, it helps.

But still, I would like to know WHY this happens? Both 5.8.0 and 5.6.0 are using the same SHA algorithm.

@e-hein

This comment has been minimized.

e-hein commented May 22, 2018

Had the same issue - for me it had not been an issue with npm but with our private package repository (nexus 3.8). To reproduce it I used npm 6 + 3 but I assume it's the same with different npm 5 versions:

Reproduce:

  1. npm publish samplePackage@1.2.3-SNAPSHOT with npm 6 (generates sha1 + sha512)
  2. npm publish samplePackage@1.2.3-SNAPSHOT with npm 3 (generates only sha1)

The 2nd publish patches the package content and the sha1-checksum but our repository still kept the sha512 checksum.

Results:

  • npm 3 ignores the sha512 and works as expected
  • npm 6 will either use an old cached version (because it's still the old sha512) or throw an integrity error but will never use the updated SNAPSHOT
    (Even after removing package-lock.json and npm cache clean --force because the nexus still keeps the old sha512 value)

Solution:

a) Try always to publish packages with a npm version that generates the both checksums. (preferred)
b) Try never to publish packages with a npm version that generates the sha512 checksum.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.