Explain how you would be able to evaluate the trustworthiness of a person asking to transfer ownership to.
Actually, it's not as hard as you make it sound: 1. - don't transfer - mark your repo Abandoned, tell people to use that other person's fork if you have to 2. - does that person have any other online presence? Long running? 3. - does he also put his face in front of the crowd? Talk at conferences? This creates accountability - someone like that wouldn't pull out the same kind of injection, because he could be caught…
This is a reasonable response.
I'm not sure why you're down voted but I gave you a up vote.
NPM needs to make accessing the source code easier. It has always bothered me that the linked repository can be set to absolutely anything the author wants.
Not sure how that would help. Anyone can publish anything to npm, it doesn't even need a repository. So unless the source code itself was hosted on npm, and the entire toolchain was controlled by npm, there's not much to do.
There's a difference between legal liability and moral liability.
I hope everyone talking about motel responsibility are donating to all the open source projects they depend on. If not I find the moral preaching a bit one sided.
You and I both know they aren't. It astounds me how many popular OSS projects are terribly funded despite how many people use them.
Well, not really. Anyone can "take it over" in the sense of creating a new, maintained fork, but the various distro package managers have policies that I think generally require some review/approval process to transfer ownership of a package they publish. I don't know anything about NPM, but imagine it's a more lax process than something like Debian. It sounds like the maintainer here did something shady or simply re…
there's a split here. Linux package managers (by and large) have a maintenance process. Programming language package managers, by and large, do not So this could happen on rubygems, PyPi, Nuget, etc
Thankfully other languages really do require less less known external packages.
Scoping dependencies to their author by default would help (not eliminate) this problem. For example, if this had been @dominictarr/event-stream the entire time, and he chose a new maintainer, that would then by definition change the name of the package to @right9ctrl/event-stream, requiring all users to intentionally change their dependency. Yes, it's painful. But it prevents getting caught out by a malicious patch…
> One solution would be GitHub support for building & publishing packages
Except you can build packages using one of a million different tools. Unless you could only publish packages that were built using specific vetted tools (and vetted plugins for those tools), that wouldn't change anything. If I can change anything in the build pipeline, I can control the output.
NPM is just a mess, and the whole culture and ecosystem that surrounds it. Micropackaging does make a little bit of sense at least in theory for the web, where code size ought to matter, but in practice it's a complete shitshow, and leads to these insane dependency paths and duplication and complete impossibility to actually keep abreast with updates to dependencies, much less seriously vet them. The insidious threat…
I don't see how this problem is limited to just NPM. This is a problem of any package manager. Or any software distribution system in general, really. Look at all the malware found on the Play Store and the Apple Store. Unless you're willing to meticulously scrape through every bit of code you work with you're at risk. Even if you can, what about the OS software? How about the software running on the chipset? This is…
The difference is that JavaScript lacks so much basic stdlib type functionality that it all has to be replaced with libraries. This dramatically increases your risks, since simple libraries will be created which become near standards, which in turn become dependencies of a huge swath of more complex libraries, meaning that any one of the dozens of crazy-common-but-should-be-in-the-stdlib libraries can be a target for hacking, social or otherwise. Also, it means that any web app no matter how trivial is likely going to itself depend on dozens or hundreds of libraries. Which means that even though the theoretical risks of depending on remotely sourced libraries are the same, the practical risks of establishing trust is exponentially harder for JavaScript than for nearly any other popular language out there.
NPM needs to make accessing the source code easier. It has always bothered me that the linked repository can be set to absolutely anything the author wants.
I think something like an npm diff command would be helpful. This would allow you to see the changes from a previous version that you just upgraded from. This would somewhat replicate the functionality that commiting your node_modules directory to git would give you.
I'm pretty sure they'll be legally liable for intentionally inserted malicious code, no matter what the license text says. I'm not talking about the original maintainer (who didn't introduce malicious code intentionally), but the person he turned it over to (who seems to have). Legal liability and ethical responsibility are not always the same thing, although it's generally only the first that matters in court.
oh sure the criminal who put the backdoor in place, no-one's arguing his/her liability. But the point that I was referring to is any suggestion that the repo. owner who handed it over could bear any liability for doing so, I'd suggest that's not probable/practicable.
I don't see how the text of the MIT license can be construed to indemnify a negligent developer but not a malicious one.