-
|
One persistent concern I've seen since package-lock.json was introduced was that on a fresh I talked with a handful of folks earlier in the year and this was by far the most consistent piece of feedback I heard in terms of a paper cut that introduces uncertainty, frustration, and concern. There is also historical concerns that've been voiced in various official npm spaces, for reference:
It seems that in the Community site there was a "solution" that requires additional steps, including a forced cache clean and using |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 5 replies
-
|
Is this still an issue on npm v7? It should be always saving with https whenever it's a registry request, regardless of what the dist.tarball says. Also: any tarball being fetched from the registry will be fetched via https if the (And, while I realize this point addresses the issue exactly 0%, since it's not strictly a rational concern, if the registry packument is fetched via https, then you have a cryptographically secure hash of the contents served over https, so there is really no way a MITM could change the tarball contents in flight. While it's definitely bad to send the contents of private packages over an unencrypted channel, for public packages, we're really just hurting the environment with unnecessary compute expenditure by forcing every tarball to be sent over a TLS connection, but again, this convinces no one, so we do yield to popular demand and perform the unnecessary crypto.) So, my feeling on this is that the issue is likely fixed, well beyond any rational need. If you can repro a npm v7 cli switching the urls in a lockfile from https to http, that's a bug that we'll get on asap. |
Beta Was this translation helpful? Give feedback.
-
|
You can run your install with |
Beta Was this translation helpful? Give feedback.
-
|
Ah, I was wrong, if the package-lock is already http:, then npm v7 won't update it. But it will still actually fetch the tarball over https. |
Beta Was this translation helpful? Give feedback.
-
|
Is there something actionable here? If so would it make sense to make a tracking issue in npm/cli? |
Beta Was this translation helpful? Give feedback.
-
To answer this: I don't know. I've not seen it happen frequently enough to know what does and does not trigger it. If the code that would solve Given that this is a consistent concern that I've heard from folks as recently as February, perhaps it's worth noting that this has theoretically been "solved" at this point?
👍
Potentially something to include, since this would theoretically fix any old lockfiles that would misrepresent what's actually done? |
Beta Was this translation helpful? Give feedback.
-
|
I'm going to mark this thread as the answer for now unless we see that this continues to be an issue in npm 7 |
Beta Was this translation helpful? Give feedback.
-
|
I'd suggest to only store ci-concerned things (package names/versions/checksums, and who denpends on whom) in the package-lock.json, and split out otherthings into a new package-meta.json that poeople could just git-ignored. |
Beta Was this translation helpful? Give feedback.
Is this still an issue on npm v7? It should be always saving with https whenever it's a registry request, regardless of what the dist.tarball says. Also: any tarball being fetched from the registry will be fetched via https if the
--registrysetting is https, that's been hard-coded since the v5 days. I haven't seen any reports of that jitter except when dealing with caches and package-lock files from pretty old versions of npm. 6.14.8 (as seen in npm/cli#1685) isn't that old, but since it happens due to caches and lockfiles created by earlier versions of npm, which npm v6 did not correct to the same degree that npm v7 does.(And, while I realize this point addresses the issue exactly 0%, …