News for hackers. Stuff that matters.
Re:What NPM should do to stop a new colors attack by zepolen on Tuesday January 11, 2022 @02:51AM (#29888752)
> There is a social contract in the world of open source.

No there isn't. What there is however is the actual contract of the repo (MIT License):

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Listen, open source is about freedom, and the author is perfectly within his rights to freely change HIS OWN REPO as he wishes. Just as anyone is within his rights to freely FORK THE REPO.

This is open source.

Re:What NPM should do to stop a new colors attack by arcticbull on Tuesday January 11, 2022 @03:14AM (#29888898)
> This is open source.

No, it's not.

The idea that you can waive the implied warranty of fitness for a particular purpose covers good faith mistakes or omissions. It doesn't cover intentional misrepresentations or excuse blatant fraud and criminality. For instance, if you sneak in a ransomware package, it's not "all good folks" because "there's no warranty, it's my repo and you can munch on my nuggets."

The author offered something to the community on certain terms and made certain representations. The author then decided that they had sellers remorse, and instead of acting like a professional adult who realized they made a poor investment (and finding a new maintainer), they threw a tantrum and decided to try and stick it to "the man" by violating the representations they previously made to the community as a whole.

This was petty, petulant and in bad faith. Does it rise to the level of criminality? It might, IANAL though. Nobody's going to go after them because it was more immature than truly harmful.

Re:What NPM should do to stop a new colors attack by krageon on Tuesday January 11, 2022 @07:32AM (#29890748)
Perhaps it would help if you took a step back and realised you are demanding something from someone who volunteered to let you have some of their work with no guarantee other than that you'd get the work.

There was a time where we'd say "yes, this is cool. I'll use it" and we moved on. Now you can't publish something online without an army making frankly toxic demands on your time because they feel there is something wrong with what you made.

The attitude you are displaying right now is the one that birthed CoCs and the various other straitjackets that we use these days because folks have lost the ability to tell a toxic community to go jump in a lake when they make demands they shouldn't. And it is a shame, because the permissive and open climate is what makes open source: If you don't like it, you fix it.

Re:What NPM should do to stop a new colors attack by arcticbull on Tuesday January 11, 2022 @03:33PM (#29897421)
> Now you can't publish something online without an army making frankly toxic demands on your time because they feel there is something wrong with what you made.

Asking you not to intentionally break a package you know 20,000+ products rely on as a result of your representations hardly seems like a toxic demand on their time. They hadn't committed to the project in over three years. All they had to do was continue not committing to it.

Asking them to find a new maintainer or not intentionally wreck other people's work that relies on it isn't a toxic demand, it's asking for a modicum of respect.

I'm not saying you have to keep building sandcastles, im saying if you decide to stop for whatever reason its not a toxic demand to ask you not to knock over 20,000 other sandcastles on your way out - out of spite.

This feels like a clear case of stupid games -> stupid prizes.

Re:What NPM should do to stop a new colors attack by zepolen on Tuesday January 11, 2022 @05:21PM (#29899009)
That analogy needs rephrasing, the OP built a sandcastle and left instructions on how to build it which 20,000 other people used to build (their own) sandcastles.

Then the OP decided to make a new change for his own castle.

"Draw a vulgar expression on the front door."

Which 20,000 people blindly copied and then have the audacity to complain about.

Re:What NPM should do to stop a new colors attack by arcticbull on Tuesday January 11, 2022 @07:59PM (#29900908)
It's not audacity to use a piece of software in the way it was made available on the terms under which it was made available. What is audacious is simply rugging everyone that took you at your word.

[edit] To be honest you're not even advocating for a coherent model of open source software. Should everybody consuming every library fork it in case the author throws a tantrum? That hardly seems workable. The author didn't just stomp on big company sandcastles, the author knocked over everyone's. Every pet project, every startup getting off the ground.

For what? Sellers remorse. Author wrote something and gave it away, then regretted giving it away. Sorry.

Re:What NPM should do to stop a new colors attack by zepolen on Tuesday January 11, 2022 @11:27PM (#29902296)
> Should everybody consuming every library fork it in case the author throws a tantrum?

Yes you should always fork open source projects critical to your project that are not mirrored somewhere safe, you never know when they may be inadvertently deleted, that's just common sense.

For dependencies, simply pin your versions and put library upgrades through a code review, that way no unknown code enters your system. Or just wait a couple days after a new release, the shit will hit the fan from all the incompetents.

> That hardly seems workable

Right, no one wants to do the work.

> For what? Sellers remorse. Author wrote something and gave it away, then regretted giving it away. Sorry.

For what? Buyers remorse. You blindly pulled code without looking at it, then regretted pulling it. Sorry.

Re:What NPM should do to stop a new colors attack by arcticbull on Tuesday January 11, 2022 @11:56PM (#29902506)
> For dependencies, simply pin your versions and put library upgrades through a code review, that way no unknown code enters your system.

These are all solid recommendations but don't excuse shit behavior on behalf of certain poor participants in the ecosystem. Which it seems you're super eager to do for some reason.

> Right, no one wants to do the work.

I mean so far it looks like one guy lol.

> For what? Buyers remorse. You blindly pulled code without looking at it, then regretted pulling it. Sorry.

We're talking about this guy's motivations not that of the consumers.

Re:What NPM should do to stop a new colors attack by zepolen on Thursday January 13, 2022 @02:10AM (#29917721)
> don't excuse shit behavior on behalf of certain poor participants in the ecosystem

Why not? You are excusing the incompetence of everyone affected by this.

Re:What NPM should do to stop a new colors attack by ethanwillis on Tuesday January 11, 2022 @03:39AM (#29889037)
It's not a ransomware package and drawing upon metaphors like this is poor reasoning. I suggest you read some Dijkstra on this idea of "medieval thinking."
Re:What NPM should do to stop a new colors attack by arcticbull on Tuesday January 11, 2022 @03:40AM (#29889046)
[edit] The point I was making is not that the author committed a ransomware package (or even that it is a good analogy) but that the idea there is a blanket waiver of warranties that covers whatever you wish it to by virtue that it is yours is trivially falsifiable.
Re:What NPM should do to stop a new colors attack by ethanwillis on Tuesday January 11, 2022 @03:42AM (#29889057)
Sorry, I can't continue a good faith argument with someone who defines this as malware. It's delusional.

I won't edit my comment above except to note what the original parent comment was:

" The author committed malware to a package many relied on, that they had not made a commit to in 3 years. My point is not that the author committed a ransomware package but that the idea there is a blanket waiver of warranties that covers whatever you wish it to is trivially falsifiable."

Re:What NPM should do to stop a new colors attack by arcticbull on Tuesday January 11, 2022 @03:45AM (#29889072)
You are correct that calling it malware is borderline - it was malicious software designed to cause harm or nuisance (to some degree) for users. However, I have amended my comment to for clarity of intent.

The definition of malware for the record is:

  ...  software that is specifically designed to disrupt, damage, or gain unauthorized access to a computer system.
Seems close to me, the modifications were designed to disrupt the users of this package. This is not strictly relevant.
Re:What NPM should do to stop a new colors attack by ethanwillis on Tuesday January 11, 2022 @03:51AM (#29889106)
All I want to say is that if accepting your argument as 100% true, then corporations have done much worse with software end users have actually PAID for. Yet, this same community that holds this developer of software that is free is held to a higher standard they don't apply to their own commercial projects.
Re:What NPM should do to stop a new colors attack by arcticbull on Tuesday January 11, 2022 @04:00AM (#29889163)
Out of curiosity do you have some examples where customers paid for a library, and then the author of that library decided they disliked the terms of the arrangement and injected some code to make it non-functional demanding nebulous payment? Or worse?

I suspect not, because they would be sued into the dirt for breech of contract and shortly find themselves out of business. In fact I believe the customers could even sue for specific performance and force the seller to actually execute the contract as committed.

It's not that I hold free software to a higher standard, I hold folks to the standard they committed to. The author had big sellers remorse, upset that they had offered this software free of charge. I'm sorry, we all make decisions we regret. If they didn't want to maintain it anymore they could have found a new maintainer. Instead they decided to mess with the computers of people who accepted their representations.

Re:What NPM should do to stop a new colors attack by ethanwillis on Tuesday January 11, 2022 @04:19AM (#29889283)
Sure, How about Google borking a user's device with OTA updates and then telling users to go pound dirt with their silence?

https://9to5google.com/2015/04/10/nexus-5-nexus-7-bricked-an...

Re:What NPM should do to stop a new colors attack by arcticbull on Tuesday January 11, 2022 @04:33AM (#29889385)
That appears to be (a) unintentional, which is a critical distinction (b) 7 years ago and (c) if the comments section is to be believed, resolved by calling Google up, explaining the situation and receiving a complementary warranty extension.

  To their credit they stood behind it. Mine was repaired, FREE (October 2015)
The delay was, more than likely, simply that big companies move slow. This is not the same thing.
Re:What NPM should do to stop a new colors attack by ethanwillis on Tuesday January 11, 2022 @12:34PM (#29894669)
Point A is a simplification. Point B is irrelevant. If you think it's bad it doesn't matter when it's done. Or will you say that in a few years what you think is bad that this developer has done is no longer bad? This is flawed reasoning. Point C you're sugar coating it. He initially was denied and given the run around and only after making a sufficient fuss was he deemed worthy of a warranty extension. How many others weren't? It's the same thing in american healthcare where insurance companies will "Accidentally" deny coverage a few times for certain things just to get the less persistent people to give in and not bother fighting for what they're owed.

But here's the real context on Point A since you don't want to actually look into it further and most outlets aren't going to bother doing it either. Once Google realized what was happening, well, it kept happening. They were pushing these OTA updates in some cases with 0 user intervention. Not to mention you're taking the comments out of order. That specific commenter had his device bricked multiple times. Why don't you quote that part of his dialogue?

Maybe you should ask why devices would be bricked in the same way multiple times?

Re:What NPM should do to stop a new colors attack by arcticbull on Tuesday January 11, 2022 @03:27PM (#29897351)
I'm sorry but there's no comparison between mishandling a bug causing an issue for customers unintentionally, and intentionally nuking all your customers from orbit with a malicious commit because you threw a temper tantrum. There's a ton of good ways to handle this. Find a new owner, for instance.
Re:What NPM should do to stop a new colors attack by dse1982 on Tuesday January 11, 2022 @08:45AM (#29891364)
Re:What NPM should do to stop a new colors attack by hansvm on Tuesday January 11, 2022 @08:36AM (#29891281)
It happens all the time.

Some anecdata: When Garmin bought Navionics they cancelled everyone's paid lifetime licenses, pushed updates demanding logins (worse in this case than others because 99% of the places you'd use their software have shitty internet, so an intermittent login wall is a bit crippling even if it were free) and monthly subscriptions, and hounded every negative review saying that they were doing it for the users' own good. Could a person sue for $19.99 and not have corporate lawyers juggle you between headquarters in Kansas and Italy? Maybe, but it's a pain in the ass for minimal gains.

Re:What NPM should do to stop a new colors attack by zepolen on Tuesday January 11, 2022 @03:24AM (#29888957)
You should have been on the internet a couple decades ago, you'd have hated it (and we'd all have laughed at you.)
Re:What NPM should do to stop a new colors attack by 1_player on Tuesday January 11, 2022 @05:15AM (#29889635)
I don't think you remember how the internet was 20 years ago very well to make a statement like that.
Re:What NPM should do to stop a new colors attack by arcticbull on Tuesday January 11, 2022 @03:36AM (#29889022)
Thankfully, most of the community has matured in the interceding decades.
Re:What NPM should do to stop a new colors attack by zepolen on Tuesday January 11, 2022 @04:11AM (#29889225)
Actually, most of the community no longer spends their time here, but of course you wouldn't know about that, you are not invited.
Re:What NPM should do to stop a new colors attack by arcticbull on Tuesday January 11, 2022 @04:36AM (#29889399)
If it's a community of folks who release open source projects, see their success, then throw tantrums I mean, that doesn't sound like a loss to me. I'm happy that y'all were able to build a community on common foundations and I wish you the best of luck!