Live data from Hacker News

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

bleepingcomputer.com

441–450 of 1001 posts

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

#441
post #153

Earlier quoted context omitted.

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.

Yeah I also don’t understand. But then again.. the js ecosystem is one big pile of turds.. Tech cycles with people who reinvent the wheel and keep making the same mistakes All these problems have long been solved

They were solved in a way that slowed progress.

So invariably, people discovered that if they threw out the complexities of the solutions, they could make faster progress.

Then they eventually ran into the corner cases.

That's the time loop that keeps happening.

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

#442

Here's my $.02: Packages are literally remote code exec vulns in the hands of package authors. At the very least, it takes them under a minute to break your app, simply by deleting their package. Read the article. This is not the first time it's happened, and it's not going to be the last. [0] I write backends (mostly in PHP, although not exclusively), and I release a lot of my code under libre licenses. But I don't…

True enough overall, but I'm surprised no one has let you know that NPM actually doesn't allow you to delete packages anymore (after the left-pad controversy). You have to email them and then you are judged by how many downloads you have. If you have users relying on your package, they do not let you delete it.

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

#444

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. 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. Assuming the package is released under a Free Software licence, what grounds would there be for a DMCA takedown? I suppose a developer could include the lyrics to a pop song in their code (possibly encrypted), and then tell the copyright holder about it (since I don't think you can make a DMCA request on behalf of a copyright holder withou…

The developer can DCMA claiming the code doesn’t follow his license as famously happened with Bukkit (the Minecraft server tool).

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

#445
post #418

Earlier quoted context omitted.

> This guy abused Github to distribute malicious code to thousands of projects. He could've done far, far worse in terms of the technical impact of these changes. It's obvious that he was trying to make a statement, not exfiltrate data to sell on the dark web. It's scary because, as a FOSS maintainer, your code is your responsibility to do with what you will until it's no longer in the market's interest. You don't ha…

This wasn't a "protester". It was deliberate sabotage, done with full knowledge that it would cause major damage. GitHub is with its rights to kick this guy off. It would even be within its rights to take over that account and fix the introduced bug (by reverting the change or otherwise). That wouldn't prevent the original developer from maintaining their own broken version, but npm and GitHub could eliminate it if t…

> It was deliberate sabotage, done with full knowledge that it would cause major damage.

That's how protesting often works. Deliberately interfering in normal affairs is a very common protest tactic. Just look at the interstate shutdowns after the George Floyd killing, or going back to Rosa Parks and the Montgomery bus boycott, worker strikes, etc. etc. That's exactly how protest works.

Forcing application code to print statements like "LIBERTY LIBERTY LIBERTY" is very, very different than trying to infiltrate commercial systems and exfiltrate sensitive data.

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

#446
post #360

Earlier quoted context omitted.

I'm saddened to see you getting downvoted too (and I've tried to compensate for that). You're right that more ecosystems need something like Crev: https://dpc.pw/cargo-crev-and-rust-2019-fearless-code-reuse

Crev looks interesting. Most Linux distributions are using a single key for the signing of packages, and this might be an easier place to start changing over to a multiple signature model. In this particular case is was a single jilted developer, but determined actor could easily attack someone with access to the keys to sign compromised packages, as per the obligatory xkcd on the matter https://xkcd.com/538/ .

Multiple signatures would indeed be a good mitigation against coercion, especially if the signatories were in different jurisdictions.

Ideally you'd want a system which separates reputation from meatspace identity, so that well-trusted reviewers couldn't be easily targeted offline. Unfortunately that would require a lot of good opsec, and go against the financial incentive for someone to disclose their online identity as part of a salary negotiation, for example.

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

#447

Earlier quoted context omitted.

> That's fine, but then the downstream shouldn't complain either when the code breaks, whether intentionally or unintentionally. There's no contract that says complaining is banned.

That's the point. If the dev complaints are invalid because the contract doesn't say so, then the downstream complaints should also be invalid.

Except the license does say so

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

#448
post #101
post #43

Earlier quoted context omitted.

To resolve such issues the central maven repo, for example, makes artifacts immutable when you publish them

A key difference with Maven projects is that you specify exact dependency versions instead of “always use latest” or some variant of that, as is pretty common in the Node world.

This is not necessarily true, there are version ranges: https://www.baeldung.com/maven-dependency-latest-version

Admittedly, I don't think it has nearly as wide a usage as it has in the NPM world. Dependabot (I know I'm not the first to mention it, here, today) is probably more of a factor.

Still, it strikes me that this sort of "attack" (or mishap) is exceedingly rare in the Java ecosystem, while it's pretty common in the NPM world, and I don't immediately understand why that would be so.

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

#449

Earlier quoted context omitted.

GitHub has always been about "social coding". This is a quote on their homepage on May 2008 (three months after GitHub was founded): > What’s amazing about Github is how it really brings the social aspect into play. Chris and Tom are showing us all visually how git development is supposed to work. I know I personally had some bing moments once I started pulling in commits from external git repos. https://web.archive.…

Yeah, I was a GitHub user in 2008. Though it obviously had a social aspect, it wasn't considered a "social network" type of site. Its ongoing transformation into one is a result of the acquisition by Microsoft.

I have always considered it a social network, 'the social network for young programmers' as I called it, which turned free software into social networking (portfolio for first employment(s), etc.), and that's why I always refused to create an account over there as I don't want to push those things even further, and got gradually more appalled as I watched projects following the trend and moving there one after the other, making themselves more and more dependent of the tools conveniently provided by that silo, and cutting other ways to interact with them. Long before Microsoft entered the picture.

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

#450

Some people find this too rough, but the reality is: do not license something as MIT or any free license if you are not happy with commercial users benefiting from your work . Simple as that. None of them are under any obligation to pay, maintain, promote, or not clone your project.

This goes both ways. Don't blindly use MIT licensed code if you aren't okay with the risk of something breaking or something malicious being inserted.

malicious is it's own beast that should always be guarded against, but being MIT doesn't give someone the right to be malicious.
Post reply on HN