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

101–110 of 235 posts

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

#101

Post by sarchertech »

ricardobeat wrote: post #53
sarchertech wrote: post #47

Earlier quoted context omitted.

> This implies some kind of fairness/moral contract in a license like MIT. The license tells you what you are legally allowed to do. It doesn’t supersede basic concepts of fairness. The average person would say that if you directly make millions of someone else’s work, the fair thing to do is to pay that person back in some way. Calling someone a leech is just saying that they aren’t following the the accusers model…

> someone else’s work It is not “their” work anymore (IP rights discussions aside) once they published with an unrestricted license. That’s the point. You do it expecting nothing in return, and do it willingly. Expecting “fairness” is a misunderstanding of the whole spirit of it.

>expecting nothing in return

Let’s ignore that no one contributes to open source expecting nothing in return.

I can help someone out expecting nothing in return. Then if my situation changes and I need help, but they look at me and say “sorry your help was a gift so I’m not going to return the favor even though I can”. That person is a dick.

The problem is you are taking the act of applying a permissive license as some kind of ceremony that severs open source software from all normal human ideas of fairness. You may view it that way. Most people don’t.

It’s perfectly reasonable to put something out in the world for other people to enjoy and use. And yet still think that if someone makes a billion dollars of it and doesn’t return anything they are displaying bad manners.

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

#102

Post by ants_everywhere »

pixl97 wrote: post #86
ants_everywhere wrote: post #74

Earlier quoted context omitted.

> Cloud vendors provide security, but out of the box they don't provide secure platforms - a lot of this is left up to developers, without security experts - A lot of the spread of Shai-Hulud is due to s having overly broad credentials on NPM, GitHub and elsewhere. It's not that NPM doesn't support scoped credentials, it's that developers don't want to deal with it so it's not the default. There's no reason why, for…

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.

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

#103

Post by rs186 »

simonw wrote: post #92

Question for tanepiper: what would you have Microsoft do to improve things here? My read of your article is that you don't like postinstall scripts and npx. I'm not convinced that removing those would have a particularly major impact on supply chain attacks. The nature of npm is that it distributes code that is then executed. Even without npx, an attacker could still release an updated package which, when executed as…

Exactly.

The biggest problem with npm is that it is too popular. Nothing else. Even if you "mitigate" some of the risks by removing features like postinstall, it barely does anything at all -- if you actually use the package in any way, the threat is still there. And most of what we see recently could happen to crates.io, pypi etc as well.

It is almost frustrating to see people who don't understand security talk about security. They think they have the best, smartest ideas. No, they don't, otherwise they would have been done a long time ago. Security is hard, really hard.

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

#104

Post by aj_g »

TZubiri wrote: post #95
aj_g wrote: post #11

Anyone have a good solution to scan all code in our Github org for uses of the affected packages? Many of the methods we've tried have dead ended. Inability to reliably search branches is quite annoying here.

Any junior engineer should be able to solve this with grep in an afternoon.

For several thousand repos? Ensuring none of the 451 package versions have been installed on any branch in any repo? I don't think it's so simple.

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

#105

Post by rs186 »

watwut wrote: post #22
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.

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.

Which survey?

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

#106

Post by simonw »

2d8a875f-39a2-4 wrote: post #8

It's a stretch to pin blame on Microsoft. They're probably the reason the service is still up at all (TFA admits as much). In hindsight it's likely that all they wanted from the purchase was AI training material. At worst they're guilty of apathy, but that's no worse than the majority of npm ecosystem participants.

"In hindsight it's likely that all they wanted from the purchase was AI training material."

Microsoft already owned GitHub. I don't see how acquiring npm would make a meaningful difference with respect to training material, especially since npm was already an open package repository which anyone could download without first buying the company.

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

#107

Post by simonw »

izacus wrote: post #90
h1fra wrote: post #82

Earlier quoted context omitted.

It's a popularity issue; npm is an easy target. I don't see why it wouldn't happen to golang for example. You just need take over the git repo it's over for all users upgrading like npm

What about Java's Maven, much more popular and longer living?

What makes you think Maven is more popular?

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

#108

Post by rs186 »

righthand wrote: post #69
2d8a875f-39a2-4 wrote: post #8

It's a stretch to pin blame on Microsoft. They're probably the reason the service is still up at all (TFA admits as much). In hindsight it's likely that all they wanted from the purchase was AI training material. At worst they're guilty of apathy, but that's no worse than the majority of npm ecosystem participants.

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.

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

#109

Post by pessimizer »

izacus wrote: post #84
graemep wrote: post #45

Earlier quoted context omitted.

Why is it legally impossible to fund or contribute? Do they turn down contributions from paid developers? Do they refuse donations or just have no no mechanism for accepting them? Do they not have any form of commercial services or licence? I think there are very few projects that do not accept support in any form.

In most cases they need to be able to issue a commercial invoice in a region compatible with company accounting. For a lot of single developers that's not a thing they're ready or able to do. Those that can, usually have companies established as a revenue source for their OSS project.

> In most cases they need to be able to issue a commercial invoice in a region compatible with company accounting.

The need for this invoice is because companies cannot justify irrational spending. The have no process for gift-giving. There is almost nothing that will make spending on OSS not irrational, unless you're paying for specific bugfixes or customization work. You can't issue an invoice for nothing. How much would the invoice be for?

edit: that being said, please continue to make up any pretense to get OSS contributors paid if that's working for anyone.

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

#110

Post by ants_everywhere »

JensRantil wrote: post #96
ants_everywhere wrote: post #70

Earlier quoted context omitted.

> 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.

It's not just time. A lot of devs simply don't have the experience of dogging into third party sourcing code or understanding how one contributed to open source.

By "a lot of devs" do you mean devs at these companies?

If so I think this is a good point. It's easy to see from any one open source project's perspective how a little help would go a long way. But it's really hard to see from the perspective of a company with a massive code base how you could possibly contribute to the ten gajillion dependencies you use, even if you wanted to.

People will say things like "Why doesn't Foo company contribute when they have the resources?" But from what I've seen, the engineers at Foo would often love to contribute, but no team has the headcount to do it. And acquiring the headcount would require making a case to management that contributing to that open source project is worth the cost of devoting a team to it.

Post reply on HN