I'm starting to wonder if not the MIT license is the actual issue for this ghetto and the GPL actually got it right.
Let's be honest a lot if not the majority of programming even web apps run on the intranet of companies only. Hence the GPL is irrelevant as you are not distributing your work. Hence doing a package manager that requires GPL will not affect any of these projects at all.
For anything web facing, it forces you to disclose your code and hence you will probably improve on your codes quality and especially security which is good or you simply won't use the 3rd party code that potentially contains malware and roll your own. Which isn't nice but you now avoided this security risk.
I would also argue that unless you are a very big web company (google, twitter facebook,...) or do something security critical (crypto, banking) you will get very few if any requests for source code at all. The GPL doesn't mandate you to put the code on github but to provide it upon request. And you can charge for that. And you can provide it in physical form meaning you can ask for their postal address (and send paper or usb drive). You don't need to provide easy access to the code.
The GPL actually forces you to think about dependencies and their consequences and not just blindly use everything.
Isn't that is how its supposed to be ? Its the programmer's responsibility to ensure that the open source packages that he or she uses are safe and that they come from a reliable maintainer.
How is it different from other package managers/host. Is there anything that pip or maven do that npm should be doing ? I would really like to understand npms fault here.
I'm also pretty much an amateur here, but I think they're not criticizing npm itself, they're criticizing the "culture" behind it for lack of a better word. People are too eager to trust npm packages with questionable origins
Oh Ok. Makes sense. As I see it, a lot of development in JS is built around stitching together third-party packages, compared to other programming languages. It is by design. And in this sense, and npm just gets the blame, for being the easy means to this poor design.
I get your point. A JS developer is way more likely to easily trust and add a package to a project than say, a C or Java developer. Thanks.
Every day my company's virus scanning strips emails of zip files in case they are malicious, and the corporate proxy won't let people access GitHub because they might download something bad.
Yet the software routinely deployed at the heart of the software infrastructure goes out and downloads thousands of packages by completely unknown third parties and builds it into our most sensitive infrastructure. Even from an IP perspective this is dodgy, let alone security.
I have to think a day of reckoning is coming where these package manager systems will become major vectors for attacks.
It turned out someone had added a package to a self hosted git repo, and the developer's domain had expired. Whatever squatter picked it up set up a server that just returned a "this domain for sale" (and some ads) page no matter what the request or path was, and our build system hadn't seemed to notice.
We went to Artifactory after that. And had a serious talk in eng about code practices.
This is very typical use case of something being simple (virus scanning & attachment stripping) vs. complex ( auditing packages). People just do the simple thing because it's simple, everyone can have an input on it and it looks nice on paper to the clueless management. They usually have 0 clue about IT security.
Tools like Artifactory give you a mechanism to control/scan/cache external dependencies in a central location. They just need to be used more intelligently. But yeah, it’s terrifying to think of all the poorly written dockerfiles out there getting built via automated build pipelines that are susceptible to malicious packages.
Reminder that this maintainer gave up complete access to his extremely popular package to a bad-actor simply because they asked and had no prior showings of experience, contributions or maintenance.
I think its silly to blame the NPM ecosystem here because solving this kind of problem is extremely difficult. If we are forced to manage our own packages, we'll end up where C++ is now, where using any external dependencies is the biggest pain. What makes JS so neat is that I can npm install express and not need to reinvent the wheel.
The problem is a JS OSS Maintainer problem. Not a technical one, not an ecosystem one. Just because the MIT License relieves you of legal responsibility, it does not (IMO) relieve you of moral responsibility. If we can't trust the maintainer of a package as wide-spread as event-stream to either hand-off the maintenance to someone who is trustworthy or to deprecate the package, then how can we trust anything they maintain? Software maintenance is a responsibility.
Although tooling won't solve the problem, having some sort of system similar to npm/yarn audit except for poor maintenance would be helpful. For example: being alerted that I am installing a package maintained by someone who changed licenses without a major version bump, gave a package to a bad-actor, fails to resolve security issues would be valuable when evaluating if a package is viable.
> because solving this kind of problem is extremely difficult
No it is not difficult. The only reasonable solution for the npm problem is non-existence of npm. Package managers are solving a problem that is not really a problem at all, and should not really be solved. Third party dependencies are bad and costly, no way around it, and any tool that makes accessing third party dependencies easier is nothing but a Trojan horse.
> where using any external dependencies is the biggest pain
And this is a good thing. It must hurt. Doing the wrong thing must be painful. Maybe this way dumb substandard developers will realise that using third party libraries is more often wrong than not.
> What makes JS so neat is that I can npm install express and not need to reinvent the wheel.
How is that special to JS? I've developed using Android (gradle), PHP (composer) and C# (nuget or whatever), and all of these environments had package managers that didn't need 1GB of ram to build a simple dependency tree like NPM.
Well first off, NPM's resource utilization isn't the cause for concern here. I have 8GB of RAM, I can spare 1GB of it while installing my packages.
Secondly, coming from a C++ background myself, it used to be incredibly difficult to pull 3rd party libraries into your software, requiring complete linking of those libraries with no standard way to install and hook into those dependencies. You were expected to download a TAR file and then you needed to go out and install all your dependencies dependencies.
Finally Nuget (or whatever) is subject to the same issues that NPM is in terms of package trust. `event-stream` was not some obscure package.
> I have 8GB of RAM
But my VM on digital ocean has only 1GB, so it's an issue. I'm not deploying to my laptop.
> coming from a C++ background myself
Yes, everything in C++ is garbage. That doesn't make NPM good.
> Finally Nuget (or whatever) is subject to the same issues that NPM is in terms of package trust. event-stream was not some obscure package.
Again, how does this make JS better?
> What makes JS so neat is that I can npm install express and not need to reinvent the wheel.
reinventing the wheel is a good idea if the existing wheel is stealing money out of your wallet.
It has often been pointed out that reinventing the wheel is a horrible metaphor, because the wheel is an almost timeless piece of engineering, and it does not get much better than that both in its simplicity and its ability to get its job done. If one thing in the software world is ubiquitous, then it is its lack of wheels.
Code reuse is an extremely important thing. I love C++ but my number one reason for not using it more is that pulling in external packages is the most difficult thing. Having a similar "ecosystem" for JS would be absolutely crippling.
For example, easy access to packages means that its easier to include libraries that add support for older browsers, like modernizer and polyfills included through babel.
Sure. "Reinventing the wheel" might be a poor metaphor, but there's no way I'd have the time to personally rewrite TypeScript, Webpack, Babel, Lodash, React for my own projects.
You already have all of the tools you need. The source code for these packages is available and you can look at it before you use it. Nobody is forcing you to download any code that you don't want to use.
And what are you going to do when npm tells you there are 13 critical vulnerabilities in your packages? Not update until you personally verify the owner of each package hasn't changed? The whole ecosystem feels like a house of cards to me.
The problem seems to be that the expectation of what the owner of an open source project is supposed to do, does not match up between the users of the product, the maintainer of the product, and in this case the reddit/ars masses.
This is sensible. The concept 'open source maintainer' is just a made up term. It is not trademarked; there is no officially recognized guideline.
Perhaps in this case the author is an utter buffoon (More on that later), but perhaps there is more to the story. Even if there isn't, there will always be scenarios where open source maintainer pulls move X, justifies it based on to them sensible reasons (probably involving lack of monetary recompense), and yet those using the package also aren't really understanding how move X is anything but a deplorable, boneheaded move that is worthy of many comments, reddit posts, ars blogs, etcetera.
Some sort of curated common list of rules, curated by some party who knows what they are doing (probably a community), where each rule has clickthroughs to get to detailed explanations and examples, plus some way to decree that you will stick to these specific rules should help. I can definitely see one of the rules being that you don't hand off packaging and/or commit control to a party unless you have done some basic vetting of said party to be on the list. Even the author of npm module event-stream would probably agree that IF said author has explicitly agreed to hold themselves to this hypothetical list, AND hadn't used public channels to distribute the fact that the author can no longer maintain their commitment to this list, then this action of handing it off to the first person to mail an offer, is an immoral/bad move worth all the scorn he's getting.
Perhaps such an entity ought to exist, but who is going to do the legwork of putting in at least SOME effort to ensure adherence to it? How do you relay communications that someone wants to renege on their promise (which should be possible; without such an opportunity it's rather a daunting thing to commit to adhere to it, forever, with zero monetary compensation)?
Tidelift gets corporations who want this kind of thing to not happen to them, to pay for support. Support in the sense of mapping out all the deps some company is using in their entire portfolio of products both internal and external, ensuring this specific scenario is not happening with them, and ensuring all licenses are clear and match company's expectations. As a bonus, the money tidelift gets is (mostly) redistributed to any major open source project who is willing to make a few fairly simple commitments (including still being actively involved in maintenance, and confirming licenses and the ability for the authors to make that claim, i.e. promises that no significant chunk of code is coming from license-wise unvetted sources), and who are willing to use APIs to communicate version updates and security usses.
DISCLAIMER: I am a maintainer of an open source project (Project Lombok) who has been approached by tidelift.
NB: IF true that the author has indeed rejected a push req to remove the one-liner pad-left esque dependency of nice-try based on the notion that this goes against their ideas on code reuse, whilst holding to the notion that an open source project maintainer doesn't really owe jack to its users, then the author is a buffoon: These 2 things are mutually incompatible. In fact, one mindset is the major argument for the failure of the other. You can't honestly ascribe to both of these mindsets (which I translate as: "All responsibility for vetting your open source deps lies with you, any reliance on the maintainers is a bad idea" mixed with "It is less effort to farm out a 15-character code snippet to an external dependency than to write that yourself" are utterly incompatible notions).
I like how it was necessary to throw the entirety of open source software under the bus there. Thanks, Dan Goodin. You are another brick in the wall of why I finally let my Ars subscription lapse after more than a decade, and having been an Ars forum regular since the Celeron overclocking days.
You are [completely safe](https://www.bleepingcomputer.com/news/security/ten-malicious-libraries-found-on-pypi-python-package-index/).
This; Want to decrease house break-ins? Remove all windows from houses, ridiculous security hole, just need a simple "scripted brick" to get in, but without a window u don't get nice light and the potential to control fresh airflow into your home.
We accept this, because we silently assume the law and the police enforcing it will keep us safe. We risk losing our possessions and possibly our life, simply because we want light to get in.
The average house window is a ridiculously weak design choice from a security point of view. Easy to break in to, and u can see what's inside without curtains. Something similar in IT would be laughed at all day, but how many have bulletproof glass or steel bars in front of their own house's windows?
I mean if burglary never happened, then call me paranoid, but I think there were more breaks-ins this week alone than there was malice in NPM repo over it's entire lifetime, and I wouldn't be surprised if many used the "window security hole" to get in. I might be overly logical in this, but the statistic, and the attached emotions for many does not seem to match AT ALL.
Perhaps it's bad, but then again, one could argue that in one of the most globally accessible open source code repos, having just one malicious code example get in every month to me is actually amazingly low. House burglaries happen daily, but people accept "the house standard" still all the same? Double standards everywhere.
Exploiting css parser bugs was actually part of day-to-day development, to work around differences in browser support. Browser-breaking exploits were surprisingly uncommon, though. Bad guys didn't really consider the browser a target back in the day. If an exploit was found, it would stay around for a long time, as most internet connections were too slow and costly to use for automated uploads.
^(God, I'm getting old)
A hacker or hackers sneaked a backdoor into a widely used open source code library with the aim of surreptitiously stealing funds stored in bitcoin wallets, software developers said Monday.
The malicious code was inserted in two stages into event-stream, a code library with 2 million downloads that’s used by Fortune 500 companies and small startups alike. In stage one, version 3.3.6, published on September 8, included a benign module known as flatmap-stream. Stage two was implemented on October 5 when flatmap-steam was updated to include malicious code that attempted to steal bitcoin wallets and transfer their balances to a server located in Kuala Lumpur. The backdoor came to light last Tuesday with this report from Github user Ayrton Sparling. Officials with the NPM, the open source project manager that hosted event-stream, didn’t issue an advisory until Monday, six days later.
NPM officials said the malicious code was designed to target people using a bitcoin wallet developed by Copay, a company that incorporated event-stream into its app. This release from earlier this month shows Copay updating its code to refer to flatmap-stream, but a Copay official said in a Github discussion that the malicious code was never deployed in any platforms. After this post went live, Copay officials updated their comment to say they did, in fact, release platforms that contained the backdoor.
Copay removed the reference to the malicious flatmap-stream module after the attack came to light on Monday. The company continues to investigate the attack. It is also contacting copay-dash, another developer that uses the same open source code in its wallet app.
“This compromise was not targeting module developers in general or really even developers,” an NPM official told Ars in an email. “It targeted a select few developers at a company, Copay, that had a very specific development environment set up. Even then, the payload itself didn’t run on those developers’ computers; rather, it would be packaged into a consumer-facing app when the developers built a release. The goal was to steal Bitcoin from this application’s end users.”