Live data from Hacker News

Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

bleepingcomputer.com

791–800 of 1001 posts

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#791
post #604

Earlier quoted context omitted.

Dependencies are a major attack vector now. Tread carefully with all the supply chain attacks out there, it might not even be the authors doing these. We are entering a dependency attack massive war. Dependencies are a balance but also a sign of weakness of a system in the modern day. There at least needs to be delayed, dependency bot like analysis before you integrate. Even then, they just leave your systems open to…

Crazy what happens when you decide to freeload off a stranger’s code who you have no contract or agreement with whatsoever, beyond a license you must accept to use the software which disclaims any warranty whatsoever, even fitness for any purpose. I have zero sympathy for anyone complaining they were hurt by this. I think Marak is teaching an important and principled lesson here.

Lesson learned:

- Don't rely on open source software. It's all FUD. Always use software from companys you can sue by a contract.

- If you need an an open source library to color your console output, pay them 6 figures per year.

SCNR

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#792

Earlier quoted context omitted.

OK, but none of those little fiefdoms are "Linux".

I literally said the Linux stack which includes everything from the kernel to init to libs. You can't run just the kernel.

It's still a false equivalence. You'll agree that all the important bits of the Linux Stack are audited and reviewed by multiple people, right?

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#793
post #580

Love to see it. About time open source devs started fighting back against the Silicon Valley techbro founder scum who've been shamelessly exploiting their idealism and naivete for decades

you love to see people indiscriminately pushing malware to random servers without knowing what the server even does?

I love how you describe this as “pushing malware to random servers”.

Maybe if he included a backdoor in previous versions and now dispatched infinite loop from his C&C server, sure. But he published a new version of his library, which was literally pulled by the affected parties.

I’m pretty sure that was illegal in the US, but that’s multiple-felonies-a-day-land anyway.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#794
For myself, I tend to avoid dependencies that I didn’t write.

I use a ton of my own packages. Most of my published work is stuff that I developed for my own consumption. I publish them as standalone projects; complete with tests and documentation. Doing it this way, vastly improves the Quality of my work. It’s a pattern that I have been observing in highly competent engineers, for decades. I make these packages available for others to use, but don’t really care, whether or not they use them (which is good, because very few people use my stuff).

I think, in all my projects, I only use four external dependencies, and two of them are in an experimental project (one, being ffmpeg, and the other, a simple built-in Webserver package). A third, is a paid extension, in a “semi-experimental” project (a SOAP library in an ONVIF driver). The fourth, is a keychain wrapper that I use in a couple of projects. It is something I could write, myself, but appreciate not having to. I think I might use VLCLib somewhere, but I'm not sure if I have published it. I know that I played with it, at one time.

If I do use an external dependency, I check the code, and the author. I don’t do a full audit, but I make sure that it is well-written and maintainable, in case I need to pin/fork it. If they offer it as paid, I’ll often use that option, unless they are asking a ridiculous amount (in which case, I’ll find another option). The presence of a paid option is generally a sign that the developer is serious about supporting their library. I will check out the author. I tend to look for experience and competence, as general qualities.

If I find issues, or have requests, I’ll communicate with the author, through their preferred channel (like GitHub issues). I try to be respectful and polite.

I do use a number of StackOverflow-inspired (or other sources) snippets. When I do that, I never use the code directly, but take it apart, and put it back together, in my style. I also reference the source, in my headerdoc comments. I always make sure that I completely understand the code.

I only have one project that I authored, “go viral,” and I have turned it over, completely, to a very capable team of folks. I no longer have much to do with the project, and that’s by design. I”m very glad that it took off, as it helps a lot of folks, and I’m extremely grateful to the team that adopted it. I trust them to be good stewards.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#795
post #705

Earlier quoted context omitted.

> DMCA is an entirely different beast, and it's not Github's fault that whole system is broken. Microsoft and co. probably have the leverage to move that needle a little if they really wanted to.

No, they don't. Companies don't fuck around with the DMCA stuff.

And that's exactly why it's not worth it to keep your data on such services. Someone can make an unsubstantiated DMCA claim and in most cases your account will be taken down automatically without even any human verification. Which means that even if you did nothing wrong, you will still lose all your data.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#797

Earlier quoted context omitted.

It's not a language problem. It's a cultural problem. Last I checked create-react-app pulls around 1k transitive dependencies. Can't really blame JS for that, can we?

Keeping dependencies loosely coupled and reusable has been best practice since forever, but it is only really with NPM that it has become the default.

But actually it's more like dependency hell because you pull in the same dependency in N versions and you can't update transitive dependencies in a senseful matter? And you get a lot of libraries that are like 4 lines and computing basic operations (like there was a lib "isOdd"... i mean x% 2 === 0?).

So you won't gain anything from this type of dependency management, because it is way to complicate to understand and to manage for a developer.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#798
post #750
post #722

Earlier quoted context omitted.

Security auditor here. Every time I see a client importing unsigned code with no evidence anyone they trust has reviewed it, I flag it as a supply chain attack vector in their audit and recommend mitigations. Some roll their eyes, but I will continue to defend it is a serious issue almost every company has, particularly since I have exploited this multiple times to prove a point by buying a lapsed domain name that mi…

If we are willing to admit that repositories like npm are useful, what can be done to mitigate these issues? Is there some tooling we can build?

A meta repository that lists versions reviewed by a trusted group of people? It would ad latency to bug fixes and limit the amount of available libraries, but would prevent single developers from taking down the ecosystem on a whim.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#799
post #134

Earlier quoted context omitted.

That's fine, but then the downstream shouldn't complain either when the code breaks, whether intentionally or unintentionally. The contract on paper disclaims all liability after all. There is a social contract and then there is the literal contract. A lot of commenters here seem to be willfully obtuse or simply ignoring the former.

There's a difference between stopping to give away your stuff for free and acting maliciously. If I give away donuts for free and stop at some point, you have no right to complain. If I poison the donuts because you should've really thrown money at me for those donuts that I explicitly marked as free , I think you could complain after all.

If someone was offering free donuts with a sign that looked anything like the MIT license, you would be a fool to eat them.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#800
post #763
post #474

Earlier quoted context omitted.

I use an .npmrc in all of my repos that turns this off. It doesn't help nested dependencies but at least it reduces some of the headache.

Can you share it?

Sure, save this to `.npmrc` right next to your `package.json`. It doesn't retroactively change versions, so any existing ~ or ^ ranges need to have those characters removed. But further `npm i` invocations will save the versions without range characters.

    save-exact = true
    package-lock = false
    update-notifier = false
Post reply on HN