NPM Vulnerability Discussion on Twitter

https://www.solipsys.co.uk/Chartter/1523831884786151424.svg

by ColinWright • 4 years ago

140 192 4 years ago

solipsys.co.uk

ColinWright19• 4 years ago

Yes, I know, some of you will hate the layout with a passion. But this kind of diagram is the only way I can make sense of the back'n'forth that sometimes happens.

If you prefer Twitter's rendering then just click on a node and that tweet will open for you.

Edited to fix a typo ... thank you Jonn. Oh how I hate auto-corrupt.

thinkingemote• 4 years ago

I like it. The spatial element gives some pointers towards order in time too. I think ordering by importance (most quoted, replied) takes precedence.

zwp• 4 years ago

This old dog is reminded of trn(1), "threaded read news".

See top right: https://upload.wikimedia.org/wikipedia/commons/d/d8/Trn_cons...

junon• 4 years ago

Actually prefer this to Twitter. Easier to read.

ColinWright19• 4 years ago

It is until the discussion gets really big. When there are several hundred tweets there's no good way to layout the graph. Then you need folding, but even then, folding in the 2D environment gives you a much better sense of the discussion.

Zealotux• 4 years ago

I enjoy this layout and I only wish it had some sort of check for background color contrast accessibility.

ColinWright19• 4 years ago

Yeah, the colours are a complete hack. There are so many things this needs to make it more usable, but I have neither the time nor the skillz.

3np2• 4 years ago

I don't suppose the source that generated it is available? :)

ColinWright19• 4 years ago

Not yet ... working on a few issues.

1970-01-01• 4 years ago

I find the diagram very easy to quickly understand everything. Well done! Haters gonna hate no matter what you do.

akkartik• 4 years ago

What do you think trn/slashdot/HN-style threading is lacking?

ColinWright19• 4 years ago

Any kind of sense of where I am in a discussion.

If you find the trn/slashdot/HN-style threading better than the 2D graphical layout then I doubt I can explain to you why I find it (the threading) lacking.

skulk• 4 years ago

Your algorithm to embed a graph in 2D is intriguing: https://i.imgur.com/7xhl7VY.png

What kind of curve is this?

ColinWright19• 4 years ago

It's just using GraphViz.

shabbyrobe• 4 years ago

I love this visualisation. Is the script to generate it publicly available?

ColinWright19• 4 years ago

Currently not, there are significant problems that I'm trying to solve before making it available. No, I'm not trying to make it perfect, but I'd like it to be actually usable before opening the code.

tzs4• 4 years ago

It would greatly help if there were some text in the upper left saying that there is a large diagram on the page but you may have to zoom out or scroll to see it.

All that shows up on an iPad at normal zoom is a white page. I waited quite a while thinking maybe it was just generating something client side and that was taking a while before I noticed that there were scroll bars (both vertical and horizontal) on the page and their thumb size indicated I was only seeing a tiny fraction of the page.

On my desktop it depends on what I was doing previously. About half the time my browser window won't be big enough for anything to show up in the initial view.

ColinWright19• 4 years ago

I agree completely, but I've tried many times to figure out how to do that, and I've had no luck. I don't have any front-end skillz. If you can tell me how to do it, I'd be grateful.

Thanks.

baisq2• 4 years ago

The only thing I take away from this is that you should not use custom domains for your email, at least for important stuff.

3np2• 4 years ago

...or just make sure you keep them under your control...?

Losing access to an account at a major mail provider seems more probable than losing control of a domain you paid for.

KMnO42• 4 years ago

Eh, it happens. I pay over $200/year for my domain + GSuite. It’s a luxury I enjoy, but a luxury nonetheless.

If I couldn’t afford that anymore, I’d probably go back to Gmail. I’d probably think to switch over many of my email addresses (for services that I use), but some may slip the cracks when the domain expires.

lrvick3• 4 years ago

I checked the password-reset flows for most major NPM contributors that use regular webmail accounts like Gmail too.

< 10% had useful 2FA enabled. Most were just password reset questions or had a backup email to some old expired and re-registerable forgotten earthlink accounts etc.

I do this stuff all the time. I looked up the password reset questions controlling the zoom.us domain 2 years ago and collected an insulting $200 bug bounty for it. Zoom, like NPM, didn't do signed binaries, so this would have been brutal combined with other issues I found.

The solution is what all sane OS package managers do: code signing.

NPM has rejected this at least as far back as 2013 when they refused a PR by someone that implemented it for them: https://github.com/npm/npm/pull/4016

I don't know what else to do but keep publicly trolling them at this point until code signing is implemented. Unsigned code is a free pass for remote code execution when an account gets taken over.

Meanwhile Debian maintains hundreds of signed nodejs packages proving it is very doable by a low budget team. NPM seems to just want to reduce deveopler friction at all costs :/

pimterry• 4 years ago

Doesn't really even need to reduce average developer friction - they've proven a few times that they're happy to add extra security requirements just for publishers of high-visibility packages.

"Once you cross 100,000 weekly downloads, all new publishes must be signed" would keep the easy on-ramp for small packages but dramatically reduce the risk of major attacks against all the big targets (like the example here).

Not as good as signing everything, but a good start that can be iterated on later.

sofixa• 4 years ago

Is code signing really a solution here? It seems more like a bandaid to me, because someone without MFA on their account probably also doesn't have the best security around their code signing. In any case, isn't it often handled by CI/CD? If you get access to the developer's account, you can release malicious code, dutifully signed?

dncornholio• 4 years ago

I don't know what else to do but keep publicly trolling them at this point until code signing is implemented.

I don't think your trolling is doing you any favours anymore (sigh, that guy again). Kicking a dead horse etc. Maybe just let it go?

JackC• 4 years ago

The question in that thread, and this later thread,[1] is how to know which keys are valid to sign a package.

For example: I go to release a new version and I've lost my private key, so I roll a new one -- this will happen often across npm's 1.3 million packages. Do I then ... log in with my email and update the private key on my account and go about my business? What process does npm use to make sure my new key is valid? Can a person with control over my email address fake that process? How are key rotations communicated to people updating packages -- as an almost-always-false-positive red flag, or not at all, or some useful amount in between? If you don't get this part of the design right -- and no one suggests how to in those threads -- then you're just doing hashes with worse UX. And the more you look at it, the more you might start to think (as the npm devs seem to) that npm account security is the linchpin of the whole thing rather than signing.

It's not just npm; that thread includes a PyPI core dev chipping in with the same view: "Lots of language repositories have implemented (a) [signing] and punted on (b) and (c) [some way to know which keys to trust] and essentially gained nothing. It's my belief that if npm does (a) without a solution for (b) and (c) they'll have gained nothing as well." It also has a link from a Homebrew issue thread deciding not to do signatures for the same reason -- they'd convey a false expectation without a solution for key verification.[2]

[1] https://github.com/node-forward/discussions/issues/29 [2] https://github.com/Homebrew/brew/pull/4120#issuecomment-4068...

jacques_chester3• 4 years ago

< 10% had useful 2FA enabled.

I expect this to change. NPM will roll out mandatory MFA for the most-downloaded packages[0] (RubyGems as well[1]). I expect this will rise to a 100% requirement at some point because Github's decision to require MFA by the end of 2023 will massively raise the waterline of folks who have the capability to MFA and experience with MFA.

[0] https://github.blog/2021-11-15-githubs-commitment-to-npm-eco...

[1] https://github.com/rubygems/rfcs/issues/35

merlinscholz• 4 years ago

Yes, better use Gmail and loose your whole account in a few months/years

baisq2• 4 years ago

Yes, it's better that your account gets locked and everybody loses access to it than it is to allow someone else access it.

WesolyKubeczek• 4 years ago

Now I want this to be the default twitter ui so much.

azemetre• 4 years ago

I found it very confusing, is the chart trying to be a timeline?

noway421• 4 years ago

I think the main thread is on the left with the reply/qt sub-trees on the right. You can only read the first column. I quite like the layout, if there's only 1 main thread that i need to be aware of it's quite nice. This layout probably won't work if there's more than 2 people in a conversation.

The layout is actually not that much dissimilar from what twitter already has, just more info from non-main threads and better visibility for orphan leafs.

coffeeling• 4 years ago

It tries to map the entire tree in one view.

ColinWright19• 4 years ago

No.

The chart in all forms (there's more than one) shows each tweet as a node, and arrows showing which tweets are replies, and which tweets are "Quote-Tweets".

If A->B, then B is a reply to A.

In this particular version I've taken the longest thread and laid it out on the left, allowing the other descendants to flow to the right. Another layout is to have the initial tweet at the top and lay it out as a simple tree (technically DiGraph), but that often leaves the top left corner empty, leading people who initially open it to think it's empty and close it without scrolling. Yes, they do, that's happened before here on HN, including in this discussion.

Does that help? Are you still confused? It's just a chart showing tweets, quotes, and replies.

BigJono4• 4 years ago

Fixing security issues is nice, how about we go a step further and learn to write a one or two liner instead of inundating every project with 400,000 indirect dependencies?

bayindirh• 4 years ago

No. We must move fast, break things, and trust the network (because it's reliable and all that thing).

Implementing your good code with no dependencies is heresy! It's a relic of the past.

</rant>.

On a serious note, you can implement a lot of things with a standard library of any language, and only time consuming machinery should be incorporated as external dependencies, but somebody didn't get the memo, I guess.

_fat_santa3• 4 years ago

I think these packages are just holdovers from "Before ES6". I can see it be reasonable to pull in a package like this back before the functionality was implemented in native JS. All these packages are just holdovers that are only used by:

* Legacy Projects that pulled them in way back when and never migrated to the native API's

* Inexperienced developers not knowing this is part of standard JS now.

You can't really do much about the former. For the latter though, NPM would be wise to plaster a link to MDN's docs on some of these packages.

danlugo92• 4 years ago

But "isEven"???

That's one line of code in your utils module...

EamonnMR• 4 years ago

* Tutorials written in the pre-ES6 world being copied and used in the ES6 world.

Macha2• 4 years ago

I'm not sure how to avoid this sometimes.

I have a Rust project I've been working on.

It has dependencies for:

axum: the web framework in use

serde, serde_json: Serialization of API responses

sqlx: To talk to sqlite

time: Standard datetime format with localisation and serde support

tera: templating

tracing: async logging

uuid: UUID generation

Of these, I feel they're reasonable dependencies. You could maybe quibble about uuid (which itself only depends on rng + serde with the features I've enabled), or tracing maybe, but they provide clear value.

Anyway, those direct dependencies expand out to 300-odd transitive dependencies.

So what do I do? Do I write a templating engine, HTTP server implementation, SQLite driver and JSON library from scratch to build my little ebook manager?

Tainnor2• 4 years ago

300-odd seems reasonable (or at least unavoidable, given modern realities). JS projects typically have much more, and additionally, you don't even get deduplication of modules, so you may have three different versions of the same module on disk.

65• 4 years ago

300 is nothing compared to the typical Node project. It's typical for a basic React project to have over 14,000 dependencies.

hsbauauvhabzb• 4 years ago

Browsers recently implemented uuid natively, not sure if that’s a js spec change but do check :)

_fat_santa3• 4 years ago

One of the problems I see are the super popular holdover packages before ES6 was standardized on. The tread mentions the `foreach` package. And remembering back, many previous supply chain attacks were on these small packages like: `iseven`, `isodd`, etc.

I don't fully understand why packages like this are so popular. My guess is it has to be a combo of legacy projects pulling those deps in and inexperienced developers not knowing that these features are now part of standard JS.

While this would cause controversy, I think that NPM should lock all these dependencies down and not allow any modifications. The modules would basically be passthroughs to native ES6 functionality. I'm not saying NPM should lock down all legacy packages, just the ones that implemented ES6 functionality (isBetween, isEven, isOdd, forEach, etc)

skrebbel• 4 years ago

Hahahhahh isBetween, why

Compared to that, left-pad is rocket science

_fat_santa3• 4 years ago

Nevermind on that one. I just checked NPM and thankfully that package does not exist.

daurnimator• 4 years ago

https://github.com/yefremov/isnan

An entire module for just `return value !== value;`

Vinnl• 4 years ago

Generally, I don't think they're particularly popular, but a package that depends on them is popular. Or in fact, a package that depends on that package (that depends...) is.

mhitza• 4 years ago

At least at some point I've randomly stumbled over a GitHub account that had published many NPM packages with one-two function source code. They marketed themselves as a big contributor to the NPM ecosystem, which was directly based upon the number of NPM packages published and the number of monthly downloads. Some packages seemed to take off because people just do a npm install instead of replicating a one line function, while others I think were more popular nodejs projects of this user where they tried to force as many of their own dependencies as they could.

TL;DR "SEO" spam to market ones own nodejs expertise, would not be out of the question

krembanan2• 4 years ago

ES6 really has nothing to do with isEven and isOdd

jamal-kumar• 4 years ago

truly... those are just modulo operations

aa-jv2• 4 years ago

I don't fully understand why packages like this are so popular.

I consider 'iseven' and 'isodd' to be signs that Javascript is a hellaciously engineered piece of crap that should be avoided at all costs. They're popular because Javascript is garbage.

haswell6• 4 years ago

JavaScript supports the modulo operator and the native syntax for this:

  let isEven = theNumber % 2 == 0;

There are reasons to dislike JavaScript, but this isn’t it. The native solution is about as standard as it gets.

leodriesch2• 4 years ago

I don’t get why anyone would introduce a dependency this small to their codebase.

It’s a much better choice to just copy the source code and possibly license into your own code to just eliminate the overhead.

It’s not like any of these packages depend on being updated for security reasons or anything.

bin_bash• 4 years ago

I think a lot of it is from a single engineer: sindresorhus

He’s a prolific open source author that traditionally had a lot of modularization in his packages—though I think he has started to move away from it recently. He talks about it here: https://blog.sindresorhus.com/small-focused-modules-9238d977...

Most projects will include at least one package by him in the dependency tree.

thatwasunusual3• 4 years ago

I don’t get why anyone would introduce a dependency this small to their codebase.

This might be controversial, but I think it has to do with less experienced developers, beginners, who doesn't know how to find out via "pure code" if a number is even or not, or even if something is a number (IIRC, there is an isNumber package out there as well).

I see this in other languages as well, but not in a "JavaScript scale", but that could probably just mean that the language's availability and popularity decides the number of "stupid packages."

duxup• 4 years ago

I find that I do that more often now than ever.

Most times I get the urge to pull in a rando package I find I really only need a few things it does. I check it out. Read it. Write my own.

I almost never need "all the things" outside the situations where I am using a big framework. So reading it, getting inspired / ideas from someone who did the thing and then I write a much more narrow focused version for myself.

Merad• 4 years ago

4-5 years ago (when the popularity of node was skyrocketing but es6 was still relatively new) I remember some people arguing passionately that it was good to maximize code reuse, i.e. better to pull in a package with one utility than to write 5 lines of code in your own application. I think it was mainly a symptom of the gaping holes in javascript's standard library... thankfully that attitude seems to have mostly died off.

chrisfosterelli• 4 years ago

At risk of criticism, I'll bite. I used to think this way and include a lot of small dependencies in most projects I worked on.

The thinking was as follows: Of course you could just copy the code, but then that increases LOC in my codebase that I'm responsible for. More code is more work. Lines in a dependency are the responsibility of someone else. If there's a bug, even in a small function, the community can identify it and fix it. I can get new features I might not have known I needed. I can benefit from all of these fixes indefinitely into the future without ever having to have any mental overhead about that code. So can everyone else; it's good to maximize code reuse.

I don't think I've ever used something that could be an obvious one-liner like `isOdd` but for lots of only slightly more complex stuff like left-pad, email format validation, GPS coordinate math functions -- all stuff that's really less than 30 lines -- it was really nice to just not have to think about the implementation details of that and get back to solving your problem. I could have reviewed the code or written it myself but it's just more work when remaining at a high level `leftPad()` call let's me stay focused on my original task.

That said, I've since realized I was wrong of course. Trying to maintain projects that haven't been touched in more than a year led to hours of fixing dependency issues. We switched to using dependabot, which is better, but just makes it obvious how much work it actually is to keep dependencies up to date week-to-week. Then there's all of the security issues. These days, for small packages, I advocate for reviewing the code from these packages, ensuring we understand it, and then copying it in directly with a comment for attribution. We generally try to keep dependencies low; still more than in other languages but at least some thoughtfulness about whether it's "worth it". I think a lot of the community has shifted similarly, but there's still a lot of older projects with older dependencies.

remram• 4 years ago

possibly license into your own code

This can be complicated. Depending on another package is usually very safe, at least as safe as "dynamic linking", but including code in your own source tree needs licenses to be compatible. Even then, you might have to change your license to "BSD-3-Clause + ISC" or similar composite and you will get complaints from users.

sdevonoes• 4 years ago

I don't fully understand why packages like this are so popular.

It actually works like this: Author X develops `iseven`, `isodd`, etc. No one really downloads such packages. Author X then develops `importantPackage` which does do something useful developers out here download. The thing is `importantPackage` relies on `iseven` and `isodd`. Now `iseven`, `isodd` are downloaded alongside `importantPackage`. Profit.

My point is, we should recognize certain NPM authors as toxic, but I guess "freedom of speech/code" stops us from doing so. Example of such an author: https://github.com/jonschlinkert/

broken8ball• 4 years ago

This guy would lose his shit if npm locked down his packages. I’m probably just venting but he’s been nothing but rude to me any time I’ve opened a legitimate issue on any of the larger downstream libraries of his. Not to mention, his Twitter is something else.

flatiron2• 4 years ago

I know PGP isn't perfect but why aren't packages signed by their maintainers?

cordite• 4 years ago

Who will check the signatures when so few have signatures?

What dev thinks oh I can’t upgrade because of this error, stackoverflow says use this flag —disable-signature-verification so I do and now I can develop again

flatiron2• 4 years ago

Any place with a devops team would not disable that.

progval2• 4 years ago

For what it's worth, Debian packagers check signatures when downloading from PyPI.

franciscop• 4 years ago

Overhead, and fear of losing the key and being locked out feels like two valid reasons, I'm sure there are more I'm unaware of (probably should add lack of familiarity, hence the lack of knowledge).

jacques_chester3• 4 years ago

To my knowledge NPM doesn't currently have a mechanism for signing by authors. Packages are signed by NPM itself on upload, which defends somewhat against repository compromise.

seanwilson• 4 years ago

Buy expired NPM maintainer email domains

How do people manage selling or changing a domain they've been using long-term as their primary email address for sign-ins like this? To stop a new owner of that domain from taking over accounts sign-ins that use that email address, you'd need to reliably update all your sign-in details with anything you've signed up to?

You could use a password manager to track everything you've signed into before to help with this but that's error-prone.

Alternatively, this forces you to keep paying for the old domain indefinitely?

moritonal• 4 years ago

Yes, that's exactly what you have to do. There's no way to raze land on the internet.

readmorebooks• 4 years ago

This also highlights how often developers seem to ignore mortality. When a person expires, soon will their domain registration follow.

krono• 4 years ago

The chain of trust is a lie, external dependencies are as much a trade-off in security risks as they are in production cost, and your belief in the good intentions of a person/entity does not shield you from their unintentional mistakes or oversights.

aasasd• 4 years ago

Reminder: when ‘colors’ and ‘faker’ packages printed stuff in the output in an endless loop, NPM and Github banned the author and took over the packages.

When ‘node-ipc’ overwrote all files on disk, NPM just waited while the author himself published an amendment and posted that the package ‘only created a text file, no biggie’.

infamouscow2• 4 years ago

Vendor and audit your dependencies. You shouldn't rely on GitHub to protect you from security problems.

mort96• 4 years ago

While I agree in principle, that usually means you'll 1) frequently blindly update all your dependencies, which doesn't really give you much security benefit, or 2) use old dependencies long after security vulnerabilities have been discovered in them. The first point does give you some security benefits by reducing the chance that you'll hear about a malicious package before you upgrade to it, but it's not exactly great.

I don't know what the solution is. I don't think there is a solution. We can't have 5000 dependencies from 2000 random individuals on the internet and still be safe. But if you want to avoid that situation, you're locking yourself out of the vast majority of the NPM ecosystem.

darepublic2• 4 years ago

faker was a disease that I fought against in the places where I was unfortunate enough to inherit it in the codebase. lots of devs not knowing better thinking it really made our tests more robust -- it didn't, in fact, just more flaky. also faker's functionality can easily be shimmed or rolled yourself if you want to. I will continue the fight, there are many other super popular npm packages whose value is dubious at best, cause dependency tooling headaches, and are like viruses in the web ecosystem. and the fact this faker guy sabotaged his own package is great because even before that I was against it, and now it is just easier to convince people not to import this clown lib

freeqaz2• 4 years ago

This page just shows an empty white page for me on mobile Safari. Is the site down? Does anybody have an archive link?

ColinWright19• 4 years ago

Try shrinking it, searching for text, or scrolling. It's a chart, and a small part of the top left corner is empty.

freeqaz2• 4 years ago

Thank you very much!

buzzwords• 4 years ago

I see a lot of comments here pointing to new/inexperienced developers. As one of those guys, I have to say JS community is not that great at keeping blogs/docs/tutorials up to date. Take react for example the learning section is quite out of date and no one develops using classes anymore.

hyfgfh• 4 years ago

Non-essential dependencies are for the weak and every single company that I worked for.

imdsm• 4 years ago

Myles has a good point about public email to account emails being different sometimes (https://twitter.com/MylesBorins/status/1523811989797093376). There was a way to resolve account usernames to email addresses through a quirk of the user interface up until last year. Fortunately, they're really good with dealing with bug bounties and had it fixed less than week after I reported it. That said, domain based accounts for something like this is still a big vulnerability.

Perhaps something akin to the UK OFCOM amateur radio license requirement would work, requiring people to update/confirm their details at least once every five years, or in this case, yearly?

cheshire137• 4 years ago

The link just loads a blank white page for me on mobile. Would have preferred a direct Twitter link.

finiteseries• 4 years ago

Scroll ~1000 pixels to the right and then zoom out 10x so you can click a node, skip the weird diagram, and just use Twitter.

ColinWright19• 4 years ago

As it says elsewhere in this discussion, it's not just a blank white page.

Try scrolling. Or searching. Or scaling.

There's a chart there, and you can scan the entire thread, or just click on a node to go directly the the tweet you want to see.

darepublic2• 4 years ago

What I would like essentially a curated npm, es and esm modules only and some other rules better vetting packages and their dependencies. At first almost no existing npm packages will be suitable to make the migration but I expect with just a bit of work and automation we can migrate over versions of the behemoths as well. Working with this package manager your builds can be simpler because you only deal with and target es modules. goodbye common js! goodbye leftpad! see you in hell!!

zachrip3• 4 years ago

https://twitter.com/lrvick/status/1523827220023853057

If you're trying to protect people, why release an exploit straight to the public instead of responsibly disclosing?

Edit: Looks like it's already known, hard to know that from the tweet context.

progval2• 4 years ago

It's not a new one. https://news.ycombinator.com/item?id=30403848 was exactly the same exploit.

NicolaiS• 4 years ago

The issue has been publicly known for years.

The more focus we can get the better - hopefully NPM will add MFA at some point...

Sephr• 4 years ago

NPM is a shitshow. At one point you could literally take over people's packages by asking the NPM staff nicely.

Source: https://twitter.com/sephr/status/1524080664106086400

bornfreddy2• 4 years ago

I am starting to think that what we need is package distributions. That is, forked popular packages that are hand-vetted by a group of maintainers, just to make sure that some random malware doesn't find its way into the dependencies. If you want the latest and greatest, or want your custum dependencies checked, you pay. Otherwise it's free.

I'm quite sure that the market for this is really big. Does something like this already exist?

yjftsjthsd-h2• 4 years ago

That sounds like a Linux distro with the base OS factored out; the only difference between that and, say, Debian, is that Debian is a kernel + core userspace and not just application libraries. I'm not aware of anything quite like that already existing, but OS distros are sufficient prior art for me to think that it could work.

EDIT: Actually, there are package managers + package collections that intentionally can be installed on top of an existing OS; nix/nixpkgs and pkgsrc are probably the big ones. I'm not 100% sure that those are what you want today, but it's likely that if you could get maintainers to add your desired packages they'd be accepted there.

boarnoah• 4 years ago

It also describes software ecosystems like the apache software foundation, dotnet foundation or even just community vetting like PHP has with Tidelift (which is a pretty clever idea on its own) etc...

Ekaros• 4 years ago

Isn't that kind of antifactory? Still, that also opens up the question of timely updates to solve possible security vulnerabilities.

getcrunk• 4 years ago

Is there an easy tool maybe something for ${bundler} to take your package.json and rewrite everything to refer to static versions hosted on your own cdn?

At least that way upgrades, malicious or otherwise are opt in for production

The other thing would be ideally a crowd funded resource to vet particular versions of popular packages.

TAForObvReasons• 4 years ago

For NPM use https://verdaccio.org/ . It can proxy the public registry. Install your project and it will pull and cache the dependencies. Once cached you can remove the uplink and it will only serve the cached version

NPM Vulnerability Discussion on Twitter

Related Stories