Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

tane.dev

Post reply on HN
Print view View original

201–210 of 235 posts

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

#201

Post by SAI_Peregrinus »

fleebee wrote: post #121
nemomarx wrote: post #36

Earlier quoted context omitted.

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.

Is there a real reason not to use AGPL? The fact that it makes Google very uncomfortable[1] is a great selling point to me. [1]: https://opensource.google/documentation/reference/using/agpl...

AGPL is arguably an EULA, not just a copyright license.

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

#202

Post by michaelmrose »

ants_everywhere wrote: post #70
cube00 wrote: 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.

> 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. People who work on permissively licensed software are donating their time to these Fortune 500 companies. It hardly seems fair to call the companies leeches for accepting these freely given donations.

No. People should be expected to be aware of the dynamics on which their fortunes depend. This is true of individuals and its certainly true of giant companies with thousands of employees.

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

#203

Post by rs186 »

dns_snek wrote: post #181
rs186 wrote: post #108

Earlier quoted context omitted.

Yeah, easily solved. Would love to hear your genius solutions right here that Microsoft is too dumb to come up with and implement.

Seriously? This is is extremely low hanging fruit that's not being taken care of. You shouldn't be able to take over a software dependency with a phishing email. Requiring simple PGP code signing or even just passkey authentication would eradicate that entire attack vector. Future attacks would then require a level access of access that's already synonymous with "game over" for all intents and purposes (e.g. physical…

As long as you can publish a package in a CI environment (which is essential), none of what you mentioned matters. And that's not even the point.

That phishing email is just one of the ways attackers use to infiltrate, which is not Microsoft's problem to begin with. Next time, the attacker could install malware in your machine that silently runs code and publish a package on your behalf using your own credentials stored locally while you think everything is ok, and you'd still blame Microsoft for not doing enough.

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

#204

Post by 48terry »

ants_everywhere wrote: post #70
cube00 wrote: 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.

> 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. People who work on permissively licensed software are donating their time to these Fortune 500 companies. It hardly seems fair to call the companies leeches for accepting these freely given donations.

> People who work on permissively licensed software are donating their time to these Fortune 500 companies.

They can use the software as they like, that's what the license is for. I don't recall a license or contract where I have to care about their problems, however.

If they depend on my software and it makes their product blow up in their faces and they're losing more money per minute than I'll ever make in my lifetime? Sucks to be them. I'll handle support or fixes when I very well feel like it, I'm off to play Silksong.

They can, of course, fix this attitude problem of mine by paying me.

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

#205

Post by danudey »

ants_everywhere wrote: post #102
pixl97 wrote: post #86

Earlier quoted context omitted.

I mean quite often access based errors are very opaque, I mean it is for good reason, but when you're new to something it's one of those things that leads you to give up. You want to write code, not spend 3 hours figuring out why your token doesn't work. Security things will get hacked on later, but again it will cause all kinds of problems because the ecosystem wasn't built for it.

> quite often access based errors are very opaque Yes they are, and it's hard to design good scopes especially when the project is new. A better default might just be to have the write permission expire much more quickly than the read permission. E.g. the write token might be valid for an hour and the read token might be valid for 90 days.

Two things I really wish literally any company would ever do with their systems when you have a permissions-based token:

1. Show me all the permissions that that token has been granted but has never used

2. Show me all the permissions that that token has tried to use but does not have

I would gladly accept the ability to turn on an audit mode for a given token, service account, etc., run the thing I'm trying to run, and then go look at the report to see what permissions I can remove - or, even better, have a giant "Create role from this profile" that lets me create a custom set of permissions based on all of the permissions I've used.

Google Cloud does have a thing where it shows you all the service accounts you have with "overly broad permissions", but it seems to be just "here are all the SAs with 'owner' access" so far. It didn't catch the service account we had that just needed to publish one file to one bucket but had been made a Storage Administrator with full read/write/update/delete access to every form of storage in Google Cloud.

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

#206

Post by jiggawatts »

donatj wrote: post #123

Every day I feel more and more like Go mod's decision to use the lowest common version of a dependency rather than the highest was pure wisdom. Not only does it prevent code breaking at rest from poor semantic versioning, it's also served to prevent automatic inclusion of supply chain attacks. npm as designed really aggressively likes to upgrade things, and the culture is basically to always blindly upgrade all depen…

> You have to actually review what's been uploaded to npm

Crates.io and several other popular package managers have the exact same problem. Submitted packages are essentially a blob of loose files with the source code being mere metadata provided by the uploader (or attacker!)

The logic behind this is that not every package comes from a source repository that is based on Git and there may not be a convenient and trustworthy "web link" back to the matching commit. Some SCM systems don't even have cryptographically hashed commits with the same level of "stability" as a Git commit id!

IMHO all such public package repositories should do their own Git hosting for the package file contents. I.e.: to publish you'd have to push your code to their repo instead of uploading files.

Ideally they should also scan all uploads in various ways, run reproducible builds for platforms where that makes sense, etc...

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

#207

Post by Riverheart »

rs186 wrote: post #108
righthand wrote: post #69

Earlier quoted context omitted.

It’s NOT a stretch to blame Microsoft. How many billions have we spent chasing “AI”? These issues could have been easily solved if we spent the consideration on them. This has been going on well over a decade. Microsoft isn’t any better steward than the original teams. This issue has happened Plenty under Microsoft’s ownership.

Yeah, easily solved. Would love to hear your genius solutions right here that Microsoft is too dumb to come up with and implement.

Well, from recent experience they could make “npm audit” usable without having to use a third party library like “better npm audit”. There’s no filtering or configuration at all. There are so many unimportant or irrelevant vulnerabilities reported that I have no doubt that people just ignore auditing because they don’t consider the 1000 high severity DoS vulnerabilities they can’t ignore relevant for their CLI app. =/

The tradeoff for security is usability and the worse the usability gets the more people fight back against it.

https://www.npmjs.com/package/better-npm-audit

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

#208

Post by deevus »

cube00 wrote: post #24
deevus wrote: post #17

Earlier quoted context omitted.

Could they detect code running from a new IP address or location and ask for a 2FA code?

postinstall is running on the developer's machine, from an endpoint security perspective, it's the actual developer performing the malicious actions, their machine, their IP address and their location.

That's a good point. Thanks

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

#209

Post by jlaternman »

marcosdumay wrote: post #167
austin-cheney wrote: post #146

Earlier quoted context omitted.

This sounds like blaming the victim. How do you on one hand call these people engineers, as if they are engineering something, and then on the other hand blame everything else for their inability to perform? That is weird. Its just a software platform. Would you really blame society for being too harsh if doctors, lawyers, police, teachers cannot do their jobs? It is weird to see so many people blame the web platform…

I dunno. Would you blame doctors if they were unable to perform in a single hospital and had a verifiably good track record anywhere else?

If in the other hospitals they were able to rely on the expertise of others, but in that single hospital they could not hide their lack of deep knowledge and that led to deaths? I think the answer of that analogy is obvious—though I realise it is an analogy, not directly comparable.

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

#210

Post by Ajedi32 »

watwut wrote: post #190
Ajedi32 wrote: post #154

Earlier quoted context omitted.

Working an honest job is pro-social behavior, and it is rewarded. So is quitting your job to work on a side project that ends up being valuable enough for others to pay for. It's just that giving code away for free operates outside that reward structure.

First, in your breakdown, there is literally no space for unoaid volunteer work wich is topic of the thread. Second, working job is about earning money not about helping others.

Regardless of why you do it, working an honest job does help others. Money is the reward you get for that behavior.

My point is if you explicitly choose to work for free you're opting out of that reward structure. It seems odd to do that and then turn around and complain that "the world where we are living in" isn't rewarding you for your work.

Post reply on HN