Live data from Hacker News

Oh no, not again a meditation on NPM supply chain attacks

tane.dev

31–40 of 235 posts

Re: Oh no, not again a meditation on NPM supply chain attacks

#31

I think the cooldown approach would make this type of attack have practically no impact anymore, if nobody ever updates to a newly published package version until, say, 2-3 days have gone by, surely there will be enough time for owner of the package to notice he got pwnd.

What about cases when the update fixes a security issue? Anybody using this approach would be a target for a few more days.

Re: Oh no, not again a meditation on NPM supply chain attacks

#32
post #22
post #2

> The tools we use to build software are not secure by default, and almost all of the time, the companies that provide them are not held to account for the security of their products. The companies? More like the unpaid open source community volunteers who the Fortune 500 leech off contributing nothing in return except demands for free support, fixes and more features.

Per survey I read, majority of open source is created by people who are paid for it. The unpaid volunteer working full time on something is effectively a myth.

I'd be keen to see that survey given how many projects I see with so few GitHub sponsors that I can't see how you'd derive a full time wage.

Re: Oh no, not again a meditation on NPM supply chain attacks

#33
post #21

Earlier quoted context omitted.

https://github.com/pnpm/pnpm/issues/9921

the funny thing about this is if everyone has the same cooldown, aren’t we back in the same boat? sure there are other ways for the package maintainer to notice they were pwned, but often they will not notice.

The cool down isn't for end users. It is for package maintainers and scanners.

Re: Oh no, not again a meditation on NPM supply chain attacks

#35

Earlier quoted context omitted.

I find this perspective harmful to OSS as a whole. It is completely fine to release free software that other companies can use without restrictions, if you desire to do so. It is not meant to be a transaction. You share some, you take some. It’s also ok to release paid free software, or closed software, restrictive licenses, commercial licenses, and sell support contracts. It’s a choice.

Just because you can do something doesn’t mean you should. There’s also lot of pressure for devs not to use licenses that restrict use by large companies. Try adding something to your license that says companies making over $10 million per year in revenue have to pay, and half of the comments on show HN will be open source warriors either asking why you didn’t use a standard license or telling you that this isn’t ope…

> Just because you can do something doesn’t mean you should.

This implies some kind of fairness/moral contract in a license like MIT. There is none. It’s the closest thing to donating code to the public domain, and entirely voluntary.

There are plenty of standard licenses with similar clauses restricting commercial use, no need to create a custom one.

But indeed, the truth is that a restrictive license will massively reduce the project’s audience. And that is a perfectly fine choice to make.

Re: Oh no, not again a meditation on NPM supply chain attacks

#36

Earlier quoted context omitted.

I find this perspective harmful to OSS as a whole. It is completely fine to release free software that other companies can use without restrictions, if you desire to do so. It is not meant to be a transaction. You share some, you take some. It’s also ok to release paid free software, or closed software, restrictive licenses, commercial licenses, and sell support contracts. It’s a choice.

Just because you can do something doesn’t mean you should. There’s also lot of pressure for devs not to use licenses that restrict use by large companies. Try adding something to your license that says companies making over $10 million per year in revenue have to pay, and half of the comments on show HN will be open source warriors either asking why you didn’t use a standard license or telling you that this isn’t ope…

Sidestep this debate with one trick - use the GPLv3. No company large enough to have a legal team will be able to use it, you're still squarely within the various definitions, and the FSF basically has to approve.

As a bonus maybe you can get some proprietary software open sourced too.

Re: Oh no, not again a meditation on NPM supply chain attacks

#37
post #31

I think the cooldown approach would make this type of attack have practically no impact anymore, if nobody ever updates to a newly published package version until, say, 2-3 days have gone by, surely there will be enough time for owner of the package to notice he got pwnd.

What about cases when the update fixes a security issue? Anybody using this approach would be a target for a few more days.

I know it sounds preposterous but there there are more ways to apply patches than npm pull

Re: Oh no, not again a meditation on NPM supply chain attacks

#38
post #22
post #2

> The tools we use to build software are not secure by default, and almost all of the time, the companies that provide them are not held to account for the security of their products. The companies? More like the unpaid open source community volunteers who the Fortune 500 leech off contributing nothing in return except demands for free support, fixes and more features.

Per survey I read, majority of open source is created by people who are paid for it. The unpaid volunteer working full time on something is effectively a myth.

I don’t think that is correct. VS Code developers and the TypeScript team is paid by MS. Core of React is paid by Meta, or was. Java language is paid by Oracle as is the LiberaSuite and MySQL.

Most of the Linux foundation projects, which includes Node are volunteers. Most of the Apache foundation software is from volunteers. Most NPM packages are from volunteers. OpenSSL is volunteers.

There is also a big difference between the developers who are employees on salary versus those that receive enough donations to work in open source full time.

Re: Oh no, not again a meditation on NPM supply chain attacks

#39
post #30
post #22

Earlier quoted context omitted.

Per survey I read, majority of open source is created by people who are paid for it. The unpaid volunteer working full time on something is effectively a myth.

It depends on the domain. There are a lot of critical utilities in the systems space maintained by volunteers. The “xz” compression library was one recent infamous example where an exhausted volunteer maintainer was social engineered into a supply chain attack that briefly compromised OpenSSH. Not a lot of applications being maintained by altruists, but look under the hood in Linux/GNU/BSD and you fill find a lot of…

Yes, but even in those domains those projects are minorities and in many examples they make it effectively impossible to legally fund or contribute to them from the side of corporations.

Re: Oh no, not again a meditation on NPM supply chain attacks

#40
Here’s a one-liner for node devs on MacOS, pin your versions and manually update your supply chain until your tooling supports supply chain vetting, or at least some level of protection against instantly-updated malicious upstream packages.

Would love to see some default-secure package management / repo options. Even a 24 hour delayed mirror would be better than than what we have today.

find . -name package.json -not -path "/node_modules/" -exec sh -c ' for pkg; do lock="$(dirname "$pkg")/package-lock.json" [ -f "$lock" ] || continue tmp="$(mktemp)" jq --argfile lock "$lock" \ ".dependencies |= with_entries(.value = $lock.dependencies[.key].version) | .devDependencies |= with_entries(.value = $lock.dependencies[.key].version // $lock.devDependencies[.key].version)" \ "$pkg" > "$tmp" && mv "$tmp" "$pkg" done ' sh {} +

Post reply on HN