Live data from Hacker News

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

bleepingcomputer.com

341–350 of 1001 posts

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

#341

GitHub has now suspended the maintainer: https://nitter.net/marak/status/1479200803948830724

This is scary, and I don’t know why people here aren’t losing their minds. I think someone should make a big deal about this. What would be the first step? On the other hand, my GitHub was once suspended (and all repos shuttered) for posting gists that looked like spam to some algorithm. It was extremely unsettling, and they need to do a better job communicating. But they may have suspended the account because they t…

You are saying "scary", but I think "alarming" is more appropriate.

It's an alarm that should be buzzing through sleepy programmer skulls. It should alert them to the fact that it's no longer the small company that respected programmers, where you felt your account was yours, and your repositories were yours.

The rules have changed with that acquisition, and Microsoft exploited the good reputation of that small company and the inertia of its users. Step by step, the site became more "social", and started suffering from the usual issues. Step by step, we see the same bigco policies that treat users as worker ants. When an ant starts making up a mind of its own, queen ant sends some soldier ants to cannibalize it.

Now, I realize here on HN the tired old rants of Moxie are considered gold. But if you want to skip being treated like an ant, run your own server, maybe support upcoming federation protocols to kill this centralization and bring down the nest, or at least migrate to some place that respects its users in the meantime.

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

#342

Earlier quoted context omitted.

This is true for npm. After the incident with leftpad, you can't unpublish anymore. You can, however, publish a new patch update that completely breaks everything.

> This is true for npm. After the incident with leftpad, you can't unpublish anymore. You can, however, publish a new patch update that completely breaks everything. You absolutely can unpublish, it just requires more steps. If NPM gets a DMCA takedown request they will absolutely have to fulfill it.

> If NPM gets a DMCA takedown request they will absolutely have to fulfill it.

No, they don't. Honoring DMCA takedowns allow benefit from an additional safe harbor from any existing infringement liability for the alleged infringing content, but are not mandatory in their own.

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

#343
post #157

Earlier quoted context omitted.

The problem with tree shaking has been twofold: - JavaScript is a very dynamic language with dynamic property access and a few other features that make it hard to guarantee that the linker won't accidentally remove too much - historically there was no standardized "module" format until ESM (ES modules) came up (with some time in between with few competing non-standardized proposals), so statically analyzing exports/i…

I think history (20+ years from now) will prove that for all but the smallest, almost toy, systems, dynamic typing from the 80s and 90s was a mistake. The maintenance burdens these languages are creating will make Cobol look like a kiddie bike with training wheels next to monster trucks.

I think that dynamic languages played an important role in pushing for the development of mainstream static typing that didn't suck. ML's been around for a very long time, but there was seemingly little interest in pervasive type inference in languages actually used in industry until they had to compete with the concision of dynamic typing.

Actually building large systems in dynamic languages? Probably going to turn out to be a mistake though.

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

#344
This can be resolved by just pinning version in npm, right? I mean, it's a malicious attack that compromises trust in the maintainer of the package, but it's not the end of the world for any team being conscientious of their dependencies.

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

#345
post #47

This is why you pin all dependencies and upgrade (and test) when it's convenient for _you_, not when the author pushes a new version.

The little `^` in version numbers in NPM's `package.json` file is such a bizarre choice. The fact that it by default installs all new dependencies with that means that builds on different machines at different times could result in _completely_ different artifacts.

You should always commit a lockfile (either npm's or yarn.lock) alongside package.json

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

#346
post #223

Earlier quoted context omitted.

> but I would hope that such a poison-pill would be caught long before the package became widely depended on. I'm not sure what about the current open source ecosystem makes you think anyone would catch something like this.

Funny, my company couldn't use Webpack 1 because a dependency of a dependency... depended on an ancient package from the days when it was common to not bother with attaching a license. Legally, that meant that noone could use it. In practice, nobody but our legal department cared, so we had to wait for version 2 when the dependency chain was updated to remove it.

You couldn't override the package locally? Or was too much of that code actually needed?

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

#347

GitHub has now suspended the maintainer: https://nitter.net/marak/status/1479200803948830724

People who are upset that GitHub suspended him: would you still be upset if the contents of the new package were "require('child_process').exec('rm -rf /*');"? If not, then how malicious does code have to be before a suspension is okay in your opinion?

I take it you've never read a virus magazine like, say, 40Hex or 29A?

What is "malicious code" anyway? Maybe Microsoft Windows is malicious. It does contain code to format your disk.

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

#348

Earlier quoted context omitted.

Not only does it require more steps, it also has to meet the following criteria[1]: * no other packages in the npm Public Registry depend on * had less than 300 downloads over the last week * has a single owner/maintainer So while your point is taken that unpublishing is possible under some circumstances, it is not for popular packages that are in use today. [1] https://docs.npmjs.com/policies/unpublish

None of these points have any legal standing, from a copyright perspective. https://news.ycombinator.com/item?id=29868199

Despite the need to keep it clear, copyright does not reign supreme.

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

#349

Earlier quoted context omitted.

marak has a documented history of mental illness and downright odd behavior. Talented dev and troubled individual. There's a pretty concise video covering what went down with some history here: https://www.youtube.com/watch?v=R6S-b_k-ZKY

That video doesn't discuss marak's "history of mental illness". Do you have some information on this?

Here's some information:

https://www.reuters.com/article/us-usa-new-york-bomb/new-yor...

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

#350

GitHub has now suspended the maintainer: https://nitter.net/marak/status/1479200803948830724

People who are upset that GitHub suspended him: would you still be upset if the contents of the new package were "require('child_process').exec('rm -rf /*');"? If not, then how malicious does code have to be before a suspension is okay in your opinion?

I'm not entirely versed in NPM politics, but:

1) GitHub and npm are supposed to be separate things. There might be stuff in that GH account that affects other ecosystems. By all means block the npm account, but that should be it.

2) in the end, one is responsible for the packages one pulls. We keep relearning that lesson over and over, because global package repositories made us lazy.

Post reply on HN