I wrote a piece about the latest issue in the Node.js community, where (in case you haven't read about it yet) a hacker gain access (through social engineering) to the source code of a package and added an attack, potentially stealing crypto currency wallets. You can read about it here: blog.logrocket.com/the-latest-npm-breach-or-is-it…
Now, this happened mainly due to the original maintainer not caring about it's creation anymore, but this is not the exception, but rather very common in our industry. Would you say we need to change the way we handle Open Source projects in order to help those developers maintain interest in their projects? I'd love to know what others think about that.
This isn't so much an open source issue as one of blind trust. People blindly trust packages and libraries without even bothering to look at the source code for them, often for things they are unqualified to improve, maintain, or to even do on their own without the library, framework, or whatever other crutches they are using.
When's the last time you included something from NPM and actually looked at the source code? Ever reject something because what NPM sent you was already minified or obscured, something that should only ever be done on your deployment? How often have you used a library to do something you are unqualified to even do directly? How often have you assumed the approach some lib or framework is doing is the best or even only way? How often have you verified the claims of a library in terms of its alleged quality with a code audit? Have you ever bothered to check that the code sent to you is the same as the one presented by the author on places like Github? (big warning flag if there's a mismatch!)
There are people who make claims they investigate the code they use, and I really have to call bullcookies on that. It's just another lame excuse to not put in the "Work" when long term it almost always ends up costing more in time, effort, and money. It's another of these cases of false simplicity where the "credit mentality" of "now, now, now" results in bloated expensive codebases that screws over everyone from the developers, to the product/site/program owners, to the end user. The entire attitude of "pay more later for something we can't afford now" is rampant across the entire industry, and is a piss poor approach to running any business. As Henry Kissinger joked 40 years ago, "America has gone from a nation of savers to a nation of debtors".
As I said in my own recent post on the topic:
hashnode.com/post/npm-and-blindly-including-libra…
It's the same broken mentality of blind trust that gave us the problems of running client-side code with too many privileges like Java, Flash, and ActiveX -- often in many cases to bypass protections being built into the browser for being things you should NEVER have been allowed access to in the first place... such as the lovely ability to quite often extract people's passwords from their clipboard.
You also -- as I said there -- we keep hearing people bragging about how this stuff "lowers the bar of entry for beginners" -- sometimes that bar is there for a reason. At least in terms of business coding we need a "you need to be this tall to ride" bar so we don't end up asked to "squeal like a pig" by ignorance and bad practices like a second rate Ned Beatty on a trip down the Cahulawassee river.
Unfortunately when it comes to ignorance and bad practices, so many of these "frameworks", "libraries", "includes", "modules", whatever name is hot and trendy for them this week, reek of them so bad, it often seems the people making them are not in fact qualified to write a single line of whatever the underlying language is.
Mind you it's nowhere near as bad on the back-end as it is on the front-end where such blindly included libraries rooted in ignorance -- such as bootstrap, jQuery, angular, react, vue, etc -- are the antithesis of good practices or competent process... but it's still there nonetheless.
Just look at the "function that broke the Internet" -- it wasn't even very well written; but endless people blindly included it and look at the havoc it wrought when its creator got into a spat with NPM and removed it. What if people had simply copied into their own code instead of blindly including it from a 'repository'?
How often does that blindly including not make allowances for sticking with the version that works for you, and instead just 'grabs the latest'? Whist sure there are mechanisms in place for when new versions change functionality in a breaking manner, how many people actually USE them? Sight few from what I've dealt with in cleaning up other people's messes.
Again, lessons many learned early on in client side are being ignored or forgotten both client and server-side. Don't blindly trust other people's codebases, don't create dependency hell, don't assume future versions will be compatible with what you've written forever, don't go to a library or framework for anything you cannot implement yourself without them.
But no, the "I want it now" screaming like a petulant five-year-old rules the industry, and nobody should be surprised when taking the sleazy shortcuts, failing to put in the work, mated to unrealtistic expectations and insanely short timelines whips around and starts biting people.
There's a reason it's called "Work" and not "Happy Happy Fun Time". As is oft attributed to Patton:
A pint of sweat will save a gallon of blood.
Every time you take one of these alleged shortcuts, you're rolling the dice. That's not development, that's gambling. More so when the effort to verify if what you're blindy including is any good is often more than just writing it from scratch.
Aka "the ultimate heresy". How dare anyone suggest writing something new specific to your task from scratch, when an off the shelf answer for a completely different question can have ten times the work and effort thrown at it to get a half-assed result that almost gets the job done.
I don't see any link between this sort of thing and open-source - the same thing happens with non-open-source browser plugins, apps in the app store, etc.
One thing that happens is that seemingly harmless plugins/extensions/apps are bought/given to people with bad motives, sometimes they buy them from the original owner for money, and then once the new owners have the ability to push out an update to all existing users with bad code, they do it.
Open-source doesn't need to change anything because the problem is unrelated. What we need to be aware of is how insecure grabbing packages/plugins/apps from a central repositories and accepting any & all updates that come through without any kind of review process can be a security risk.
Security is certainly low end in OSS specially in JS ecosystem, primarily because imposing strict set of standards on massive ecosystem is difficult when there is no powerful authority managing JS ecosystem.
For instance, take Apple or Google who manage and set the standards in their respective mobile ecosystem by introducing strict checklist of security measures on mobile Apps.
Assuming least/no damages done in the recent incident of npm library hack, I think people have now become cautious to include libraries written by unidentified source. They're now verifying it before directly hitting npm install ... which is a good thing IMO.
What could possibly be introduced is a concept of Certificates like we have for Websites. Some authorised source(probably by npm itself) should certify that a library is safe to use, of course, there would be a price for that but certainly makes an impact.
I'm impressed that people are advocating reviewing all dependencies. It's admirable, but I have to wonder...
It seems like you might be able to spot incompetently written code, but for malicious code, one has to assume it is hidden away in the last place you look.
It also seems really inefficient if everyone would review all their dependencies. Tens of thousands of people would review some libraries.
It'd be nice if reviews were more public. One might have more faith in a package if one knew it had been reviewed by 20 others before. But then how do you trust the reviewers?
As for open source, I don't feel that's the problem. At least with open source, you get the chance to do reviews.
As a fun fact, I once found that a library I wanted to use had a bunch of code encoded as whitespace (tabs, spaces, newlines), with two lines to
evalit. There wasn't even any malicious code, someone just obfuscated it for the fun of it...