Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps • Hacker News Board

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#881

Post by pritambaral » Mon, Jan 10, 2022, 4:17 PM UTC

esarbe wrote: post #865

not2b wrote: post #22

Earlier quoted context omitted.

In this case, the developer's behavior was malicious: they intentionally caused damage. This is very different than some good faith change that breaks stuff downstream. Sure, the license says "no warranty". But github can decide that they won't tolerate vandals on their platform. It would be within their right to revert the bad change from the git database they hold, go back to the last good change and lock the devel…

> vandals on their platform. Since it is his code; can you vandalize your own property? > go back to the last good change and lock the developer out. That's one reason for not using GitLab as source management tool. It gives them way too much power.

> GitLab

Surely, you mean GitHub.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#882

Post by Sohcahtoa82 » Mon, Jan 10, 2022, 4:17 PM UTC

xg15 wrote: post #153

drawkbox wrote: post #97

Earlier quoted context omitted.

Dependencies are a major attack vector now. Tread carefully with all the supply chain attacks out there, it might not even be the authors doing these. We are entering a dependency attack massive war. Dependencies are a balance but also a sign of weakness of a system in the modern day. There at least needs to be delayed, dependency bot like analysis before you integrate. Even then, they just leave your systems open to…

How about using dependencies but pinning the version and only updating if you know what the update contains? I'm still continually baffled that we ended up in a world where automatically accepting updates from every dev and their dog is not just the norm but recommended practice.

Because dependencies of dependencies exist, and if you use a large framework of some sort, you could end up with literally over 1,000 dependencies.

Manually checking before updating does not scale.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#883

Post by noah_buddy » Mon, Jan 10, 2022, 4:18 PM UTC

burtonator wrote: post #684

noah_buddy wrote: post #402

Earlier quoted context omitted.

The maintainer seems a few steps beyond unwell. Seems like he was planning a terrorist act of some sort. Even if one is mentally unwell, I would not first describe them that way should they choose to premeditate harm against others. If you're building bombs, you're almost certainly at that point. At the very least, the maintainer is unstable if not actively malicious and seeking to cause harm however he can.

> I would not first describe them that way should they choose to premeditate harm against others. That's why a judge often has to determine if the person is mentally ill or just a criminal. There are plenty of situations where someone has hurt other people and they've been literally insane. If your insanity causes you to believe that someone is doing horrible things like murdering children you might decide to do them…

I think it's very nearly a difference without meaning here. If you commit mass violence out of insanity, you're probably going to be in a mental hospital for the rest of your life. Functionally akin to a lifetime prison sentence in that in both cases the perpetrator is removed from society forever. It's not that I have no empathy for the mentally unwell, it's just that when your illness begins to cause actions that will harm the world around you, you're defined in terms of those acts as well as your illness. A mentally unwell person who kills someone is still a killer (I purposely stay away from murder as I do not know law or that murder can be applied to those who are not convicted for reasons of insanity).

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#884

Post by joshspankit » Mon, Jan 10, 2022, 4:18 PM UTC

sbt567 wrote: post #611

joshspankit wrote: post #542

Earlier quoted context omitted.

> Should I get paid for my multiple contributions to faker (I don't think I should)? The biggest thing that excites me about the possibilities for the future of smart contracts is that creators of all kinds could automatically benefit from any work they do. This scenario, for example: Any company that used faker.js to make a profit would have X% of that revenue feed back to the smart contracts. The creator would prob…

This sounds like a dream to me. How can it happen with open source software (where anyone can build and modify the software freely)?

In [my] ideal version of this, any monies made "down the line" from that open source software would feed back to anyone that helped build it. If 9 people contributed to a feature that a company used in their sales workflow, then each of them would get a percentage determined by the smart contract they reviewed when contributing.

If a founder came along and saw that a specific open source project could be the foundation for a business, then they could use it to build that business and feed back a portion of all profit as an operating expense. Then everyone involved would be benefited by contributing.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#885

Post by 29athrowaway » Mon, Jan 10, 2022, 4:20 PM UTC

arvinsim wrote: post #526

29athrowaway wrote: post #332

I think package managers such as npm should require package maintainers to sign a legally binding agreement that they're not going to willfully do stuff like this. There's no other way. Why? because determining if a package is malicious via static analysis or other automatic means would be the equivalent of creating a solution for the halting problem.

> I think package managers such as npm should require package maintainers to sign a legally binding agreement that they're not going to willfully do stuff like this. I would think this would discourage a lot of people to contribute to NPM. It's not about enforcement but the threat.

Sure but you cannot build something serious without guarantees.

Maybe you can set a flag in your package.json which enables only the usage of packages from authors that have agreed.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#886

Post by 0xbadcafebee » Mon, Jan 10, 2022, 4:20 PM UTC

gitgrump wrote: post #691

0xbadcafebee wrote: post #297

The software industry doesn't have any standards about how to publish or consume software, and that leads to problems like these (not the conflict over OSS, but the ability for random upstream software to randomly compromise thousands of other projects). We all live in this 'wild wild west' of software that has no guarantees of quality or safety or rigor. We could really use a regulated license for software developme…

No. JavaScript developers (and Go developers) live in the "wild, wild west". Those of us using system package repositories with proper maintainers have been doing just fine for years, thanks.

The problem is the software, not the packaging.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#887

Post by dcow » Mon, Jan 10, 2022, 4:21 PM UTC

sam_goody wrote: post #844

While I disagree with his move. 1.It is totally in his prerogative to mess up the package he manages, but not to install into it malware. I am on the fence if this would count as malware. (Because of the open loop, but my leaning is that this is not malware.) 2. Github is, IMO, breaking any trust that I might have had by assuming control of the package, removing the last commit and keeping it online. If they feel the…

I pretty much agree with you especially on the point that there are far more effective and nuanced ways to for the maintainer to have made their point, like relicensing (imagine what would happen if the license suddenly became AGPL and everyone at big corps automatically updated without checking the new license—it would be a raucous for both legal and engineering, author could offer a non-gpl version for money and probably rake in more than a 6 figure salary… but I digress).

What I find most interesting though are the ethics. The way I interpret (1.) on this comment in the context of this thread (other people have said similar things) is that the community considers the author here to be acting ethically, just annoyingly. When someone submits dubious patches to the linux kernel and wastes everyones time, it’s unethical (kernel maintainers are the victim). When researchers submit dubious CCPA requests to people on and waste peoples time, it’s unethical (webmasters are the victim). However, when a package maintainer throws a temper tantrum and fucks up everyones’ stuff and wastes a bunch of time, they’re in their right to do so and it’s pretty much just annoying but totally okay because the maintainer is the victim of something (either corporate greed or mental health issues, or both). Our society very much puts a premium on protecting victims.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#888

Post by WorldMaker » Mon, Jan 10, 2022, 4:33 PM UTC

josefx wrote: post #798

jopsen wrote: post #750

Earlier quoted context omitted.

If we are willing to admit that repositories like npm are useful, what can be done to mitigate these issues? Is there some tooling we can build?

A meta repository that lists versions reviewed by a trusted group of people? It would ad latency to bug fixes and limit the amount of available libraries, but would prevent single developers from taking down the ecosystem on a whim.

This is what `npm audit` and GitHub "DependendaBot" are both doing (originally in parallel with their own meta-databases, though now that GitHub owns npm things are lot tighter integrated, it sounds like).

Admittedly:

A) Both of these meta-repository tools are reactive rather than proactive: they flag bad versions rather than known good versions.

B) It doesn't take too many HN searches to find people don't trust `npm audit` or DependaBot either because both have provided a lot of false positives and false negatives over the years.

C) If someone does trust one or both, often the easiest course of action is to automate the acceptance of their recommendations and just blindly accept them leaving us about where we started and just blurring the lines between what is repository and what is "meta-repository". (Even the "Bot" in DependaBot's name implies this acceptance automation is its natural state, and the bot's primary "interface" is automated Pull Requests).

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#889

Post by ineedasername » Mon, Jan 10, 2022, 4:37 PM UTC

paulryanrogers wrote: post #621

ineedasername wrote: post #610

Earlier quoted context omitted.

>donations I think there is a big psychological difference (and maybe a legal one?) between accepting donations for something you put up for public access vs. accepting payment for doing work.

If so would that also impact 'backing' like KickStarter and Patreon?

I'm really not sure. I'd guess that, say, YouTubers who provide extras to Patreon supporters often feel a much higher sense of obligation.

As for the legal aspect, I'm speculating based on just a bit of knowl she about contract law: If you give something as a donation, I don't think that constitutes a contract. If you give something with the promise or expectation (by all parties) of something in return then it begins to strongly look like a contract.

I could imagine a lawsuit against a Patreon recipient if they collected $1m while promising something to supporters and never delivered. (I'm not sure people would bother with a lawsuit, but I could see grounds for one). I think it's a bit different if the exchange was more informal, like "Hey I'm making X for my own enjoyment, I hope you like it too. Click here if you want to send me coffee money" and then collected $1m on that but never finished the project.

There's a lot of subtleties though, and plenty of contract disputes revolve around whether or not a contract existed in the first place (written, verbal, or implied)

So, if you start saying "I will maintain foss project X if supporters average $Y/month" then I think that really muddies the water on legals obligations in many jurisdictions. It may not matter if you call them donations or not. After all even with donations to non profit there can be an expectation of return: a plaque on a wall, name on a building, etc.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#890

Post by Chris2048 » Mon, Jan 10, 2022, 5:05 PM UTC

detaro wrote: post #826

Chris2048 wrote: post #823

Earlier quoted context omitted.

The solution to fix FLOSS is for it not to be FLOSS?

How does a maintenance contract make the software not-FLOSS? It's a working option if you need more promises than the license gives you.

Because you haven't solved the problem for FLOSS, you've solved the problem for non-FLOSS that might also happen to also be FLOSS aka contribute somehow to a FLOSS version of the project - but the solution doesn't help those under the FLOSS licence, and complicates incentives to contribute to FLOSS/"community" versions.

Great for corporates who can buy the support contract, but is also suspiciously similar to the "freemium" model were FLOSS devs are suddenly incentivised to make the FLOSS offering insecure in comparison to the paid licence.

In this case, Marak is his own bad-actor/saboteur, how would the support contract help? It would be far more likely to make free-users 2nd class users, and as such it might be better to simply keep the products managerially separate due to that conflict of interest.

And lets be honest here - when does something stop being a reasonable "maintenance fee", and start to become rent-seeking / extortion? I think if you want to get paid, you simply don't work with MIT/GPL, or fork to a different licence; Changing your mind halfway through isn't reasonable IMHO.

MIT basically means "anyone working on this codebase agrees to MIT terms for their code, and as such authorship isn't so important". If you change your mind, you broke your agreement. If suddenly your authorship matters, what about every other author who stuck to their MIT agreement?