131–140 of 279 posts
I wouldn't use the words "malicious" or "exploit" wrt this... It's more like, I dunno, trolling on planet JavaScript? I feel like there should be a big Twitter fight about it...
Earlier quoted context omitted.
How would that have helped things in this case? If we go with the hypothesis of an angry maintainer getting revenge, would they not be just as angry at their project being forked by the community, and just as able to sabotage it via other libraries still in their namespace? (And perhaps more willing, since their original name is still around.) If we go with the hypothesis of a compromised account, people will still b…
Why would anyone who owns a namespace be willing to leave a package that's moving to another maintainer within their own namespace? A namespace tends to come with a reputation, and if you give an outsider access to the namespace, the reputation can change without the owner's consent. No, I don't think I'd be allowing @delinka/ExcellentPackage to be maintained by someone else. They can fork it to @fredralphbob/Excelle…
I wouldn't use the words "malicious" or "exploit" wrt this... It's more like, I dunno, trolling on planet JavaScript? I feel like there should be a big Twitter fight about it...
That was my first thought. But then I realized some guy basically broke something so his stuff would work and someone else's wouldn't. He didn't destroy files, but that was malicious as hell.
more like dramaticious if you ask me... but also uncovers actual dangerous weaknesses in the npm delivery pipeline...
Earlier quoted context omitted.
That was my first thought. But then I realized some guy basically broke something so his stuff would work and someone else's wouldn't. He didn't destroy files, but that was malicious as hell.
mean spirited and dramatic as hell, yes... also, a bad place where real "malicious" things could be done. but "malicious" has a specific meaning and this didn't affect users. more like dramaticious if you ask me... but also uncovers actual dangerous weaknesses in the npm delivery pipeline...
Earlier quoted context omitted.
You are arguinng a strawman. We are not discussing bugs or maintenance, we are discussing a person acting maliciously. Furthermore, you are talking about people being "stupid," which has no place in a discussion of whether a person giving away code has an obligation to not act maliciously. Never in the history of the courts has a defendant's lawyer gotten up on his hind legs and intoned, "But your honour, the plainti…
You started the thread by saying that if you used a library that is broken by the maintainer you would call that malice. Things being broken is directly related to bugs and maintenance - detecting if and how a breakage is malice is the first problem in your arguments. I'm also trying to tell you that your whole base premise is wrong, that even expecting some library to work or to keep working is too much (unless you…
In this specific case, the code was written such that it deliberately broke installation for users. I consider that malicious. The “deliberately” is the important word here.
People make mistakes. Nobody wants this to happen, but my colleagues and I have sometimes pushed a bad deploy that broke our product, and we rushed to revert to a known good state.
That’s not malice, that’s (temporary) incompetence.
But if we deliberately broke something for our users, I would consider that malice.
The real issue the Balkanization of JavaScript programs. The `rate-map` package is essentially one line of code: start + val * (end - start); https://github.com/shinnn/rate-map/blob/90c234c9/index.mjs#L...
It's an ecosystem full of reinventing the wheel. The most popular library, lodash, includes a reimplementation of a foreach loop for Pete's sake, for reasons passing understanding since it's part of the ecma spec. JavaScript is just amateur hour, and these things are going to keep happening. It's pathological.
The first only works with arrays and array-like objects.
The second works on objects and arrays, but it iterates over all enumerable properties, so you don't want really want to use it for arrays. It's also made a lot less useful because it only iterates over properties, not keys.
The third finally provides some sanity, but it's only been around since ES6. Before that, lodash's each method was the most reliable way to iterate over a collection, be it an object or an array.
Just because you don't know the reason for something doesn't mean there isn't one.
Earlier quoted context omitted.
How would that have helped things in this case? If we go with the hypothesis of an angry maintainer getting revenge, would they not be just as angry at their project being forked by the community, and just as able to sabotage it via other libraries still in their namespace? (And perhaps more willing, since their original name is still around.) If we go with the hypothesis of a compromised account, people will still b…
Why would anyone who owns a namespace be willing to leave a package that's moving to another maintainer within their own namespace? A namespace tends to come with a reputation, and if you give an outsider access to the namespace, the reputation can change without the owner's consent. No, I don't think I'd be allowing @delinka/ExcellentPackage to be maintained by someone else. They can fork it to @fredralphbob/Excelle…
Good first-principles argument, but in practice, this happens in ecosystems that do have namespaced packages. Off the top of my head:
- Until recently, kennethreitz was a GitHub organization so other people could manage kennethreitz/requests etc.
- Foursquare's Android app is still com.joelapenna.foursquared, which originally was a third-party app that got adopted by Foursquare and turned into their official app. Joe never worked for Foursquare.
- When Linus took a break from Linux development for 4.19, Greg K-H still released it from https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... and https://github.com/torvalds/linux .
I wouldn't use the words "malicious" or "exploit" wrt this... It's more like, I dunno, trolling on planet JavaScript? I feel like there should be a big Twitter fight about it...
shinnn is claiming his account was hacked, and the hacker added the code. Generally if a hacker hacks someone's npm account and adds harmful code, that would be considered malicious and an exploit.
I wonder how bad will this cred-stuffing package authors problem will get before npm/other package managers flat out require 2FA for maintainers
Better yet: use encryption keys to verify identity.
Currently, developers store npm tokens which may be stolen because they're often stored on disk or as environment variables.
Requiring developers to store encryption keys makes almost no difference: the private key will still be stored on disk and will still be vulnerable to effectively the same attacks.
There are some differences of course. Security-conscious users could use hardware tokens to store their encryption keys, and they could password protect the private key in either case. This is not the large majority of users though, so in the average case, it won't matter.