-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] Inconsistent SHA-1 and SHA-512 integrity values in registry response #2401
Comments
It seems that perhaps this
|
@isaacs Is it possible that it could be caused by the issue fixed in this commit, which was first included in pacote v10.2.0, which was brought into |
My guess, also, is that this is the downstream fix, which stops the integrity value set by pacote from being passed on to the options for the next package: 2c305e8#diff-eabad0b45ec780b8b57ae6e3d47fd7d063680bea3acdc6b98a4b45ba3b808cccR24 |
npm If your bug is preproducible on If your issue was a feature request, please consider opening a new RRFC or RFC. If your issue was a question or other idea that was not CLI-specific, consider opening a discussion on our feedback repo |
This is a security issue given this CVE against SHA1: |
@hubgit Hi, did you find the root reason finally about why the registry returns a different integrity value some times? My team encountered same issue. |
When running
npm install
we've observed that sometimes theintegrity
value for a dependency inpackage-lock.json
(and the_integrity
value in the dependency'spackage.json
innode_modules
) can change for seemingly no reason: sometimes it starts withsha1-
and sometimes it starts withsha512-
.By trying
npm install
several times while removingnode_modules
and runningnpm cache clean --force
between each run (and possibly something else), I've managed to capture two requests in~/.npm/_cacache
which exhibit this behaviour:SHA-512:
db/c0/37002f9ad0a4679e0f0266ec01808bed69f7750a20466b5f0e5c5d4f484a:d247acba954e5cb9677b6aaff7ddc3390c216575
SHA-1:
db/c0/37002f9ad0a4679e0f0266ec01808bed69f7750a20466b5f0e5c5d4f484a:f84ae26bb03fa2c70ff409926ad12c559b9faa28
The diff between these two responses is minimal, so I'm not sure why the registry might be returning a different
integrity
value each time:The text was updated successfully, but these errors were encountered: