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

Upcoming breaking changes for npm v12

github.blog

Post reply on HN
Print view View original

41–50 of 221 posts

Re: Upcoming breaking changes for npm v12

#41

Post by TZubiri »

grassfedgeek wrote: post #16
TZubiri wrote: post #5

Looks good? But doesn't this just change the compromise window from first installation to first run?

"First run" doesn't exist for JavaScript libs used only in web apps. So for that entire class of packages this change makes them safe.

But this is npm, the execution environment is not the browser, but the server.

Most packages are imported via import/require, even if it's a browser only package. Because of SSR and reasons.

Or maybe not, let's look at a random browser only example, angular and react will use SSR, so they will execute in the server, let's check Jquery:

https://www.npmjs.com/package/jquery

Docs suggest just using a script tag instead of npm, when using npm install, they suggest to run import statement, which can execute arbitrary code.

The bottom line seems to be that if you are using npm, it's cause you are using node, and therefore you will run the imported code in the server, otherwise you would use a script tag.

But maybe there's a way to define a browser only package or .js URL such that it is only downloaded and served but never executed server side?

In any case, not a huge usecase of npm, which again, is designed for node which is backend.

Randome example,

include

Re: Upcoming breaking changes for npm v12

#42

Post by therealmarv »

KolmogorovComp wrote: post #14
cute_boi wrote: post #8

They should have added a 1-day age limit by default, so security scanners have some time.

I don't think it'd necessarily be a good decision, sometimes CVE are actively exploited and need quick patching. A better safety net would be to require active 2FA proof for every package update.

As if supply chain attacks could have been prevented by 2fa or passkeys always.

You want delays by x days because supply chain attacks get caught very often within 1-2 days. And if you really really want to make an exception for a zero day then that's no problem and you can still quick patch by exclusion of that rule. They don't contradict in a unsolvable problem. You want both, you get both.

Re: Upcoming breaking changes for npm v12

#43

Post by materielle »

ralph84 wrote: post #38
aniceperson wrote: post #2

didn't know npm was owned by github.. well, that explains things...

NPM (the company) was about to go under in 2020. They raised VC but never found a sustainable business model. GitHub acquired them to keep the ecosystem alive. The acquisition hasn't really benefitted GitHub much at all.

I don’t know if this is the case here, but it’s very hard in general to judge how much software projects ought to cost.

Software projects will grow in complexity to consume whatever budget you give it. If you hire 50 devs and give them a bunch of business objectives, they are going to do what they do and write a ton of software.

It’s not obvious to me that it would be theoretically impossible to build a cheaper package manager.

Re: Upcoming breaking changes for npm v12

#44

Post by TZubiri »

tabwidth wrote: post #32
grassfedgeek wrote: post #16

Earlier quoted context omitted.

"First run" doesn't exist for JavaScript libs used only in web apps. So for that entire class of packages this change makes them safe.

Build tooling still runs though. Your bundler plugin or PostCSS transform gets full fs access at build time, nobody's auditing that.

Build deps are even disregarded as less critical than runtime deps traditionally. So deps like sphynx for building docs are still a dev side supply chain vector.

https://github.com/kennethreitz/pytheory/issues/47

The reason this may be overlooked is because build deps are only ran by the devs, but not the users, so users dismiss it as safe. However, if a build dep is infected, the infection may spread to the actual package code, which will then of course be run by the user.

Not theoretical, Microsoft is currently under attack by a worm that spreads through vs code extensions, which then spread to actual packages that users run.

Re: Upcoming breaking changes for npm v12

#45

Post by therealmarv »

alexdns wrote: post #28
jnwatson wrote: post #17

Earlier quoted context omitted.

If you need a quick patch, you pass another parameter to turn off the 1 day. 1 day delay will prevent more problems than it makes.

so this parameter can be passed by the attackers also thus making your point pointless

that parameter cannot be set by a package, you only can set it

Re: Upcoming breaking changes for npm v12

#47

Post by doctorpangloss »

therealmarv wrote: post #42
KolmogorovComp wrote: post #14

Earlier quoted context omitted.

I don't think it'd necessarily be a good decision, sometimes CVE are actively exploited and need quick patching. A better safety net would be to require active 2FA proof for every package update.

As if supply chain attacks could have been prevented by 2fa or passkeys always. You want delays by x days because supply chain attacks get caught very often within 1-2 days. And if you really really want to make an exception for a zero day then that's no problem and you can still quick patch by exclusion of that rule. They don't contradict in a unsolvable problem. You want both, you get both.

How do you know what's a zero day fix?

(You write something)

So then you have to check every package's updates and decide if you update, yes?

Re: Upcoming breaking changes for npm v12

#48

Post by monster_truck »

materielle wrote: post #43
ralph84 wrote: post #38

Earlier quoted context omitted.

NPM (the company) was about to go under in 2020. They raised VC but never found a sustainable business model. GitHub acquired them to keep the ecosystem alive. The acquisition hasn't really benefitted GitHub much at all.

I don’t know if this is the case here, but it’s very hard in general to judge how much software projects ought to cost. Software projects will grow in complexity to consume whatever budget you give it. If you hire 50 devs and give them a bunch of business objectives, they are going to do what they do and write a ton of software. It’s not obvious to me that it would be theoretically impossible to build a cheaper packa…

And additionally was it truly worth buying if this is what we've ended up with? Some things should be allowed to fail
Post reply on HN