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

71–80 of 221 posts

Re: Upcoming breaking changes for npm v12

#71

Post by woodruffw »

cookiengineer wrote: post #67

What a pointless change. If you force every user to just use "--enable-unsecure-feature", guess what will happen? This is not about improving security. This is about shifting blame. A much better alternative would've been the introduction of sandboxes or simulation runs that would output which scripts and programs are running due to unpredictable dependencies. This way the user could check before the actual execution…

I don't think it's pointless. A large number (the majority?) of users probably don't need install scripts, so disabling them by default is a net security improvement. Those that do can enable the insecure behavior, which will become an explicit decision that is trackable, auditable, etc.

You're not wrong about sandboxing, but sandboxing isn't something that can just be blithely introduced to a large packaging ecosystem that previously assumed full system access. Doing so results in the same kind of regression you point out: if the sandboxing breaks peoples' builds, they'll just disable it and move on with their goals.

Re: Upcoming breaking changes for npm v12

#72

Post by woodruffw »

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.

I think you want both of these things. Realistically we're not at a point yet where all MFA credentials are phishing resistant.

Re: Upcoming breaking changes for npm v12

#73

Post by garbagepatch »

cookiengineer wrote: post #67

What a pointless change. If you force every user to just use "--enable-unsecure-feature", guess what will happen? This is not about improving security. This is about shifting blame. A much better alternative would've been the introduction of sandboxes or simulation runs that would output which scripts and programs are running due to unpredictable dependencies. This way the user could check before the actual execution…

Most users don't need it. Having it on by default is a feature for malware writers not users.

But to your point, Node has had permission flags for a while[0] but allows everything by default. Npm could use them to increase security even more. I just hope it doesn't take them another 10 years to change the default.

[0] https://nodejs.org/api/permissions.html

Re: Upcoming breaking changes for npm v12

#74

Post by Dylan16807 »

ok_dad wrote: post #56
w29UiIm2Xz wrote: post #24

Earlier quoted context omitted.

To be fair, the vibes (at the time) were that Microsoft has changed. Probably, in some way, a zero-interest rate phenomena.

Young people thought M$ was changing, the old folks knew it was just another cycle of embrace, extend, extinguish.

Microsoft has been causing a lot of problems lately but I completely disagree that it fits the pattern of "embrace, extend, extinguish".

Re: Upcoming breaking changes for npm v12

#75

Post by recursive »

cookiengineer wrote: post #67

What a pointless change. If you force every user to just use "--enable-unsecure-feature", guess what will happen? This is not about improving security. This is about shifting blame. A much better alternative would've been the introduction of sandboxes or simulation runs that would output which scripts and programs are running due to unpredictable dependencies. This way the user could check before the actual execution…

I'm not going to get forced.

Re: Upcoming breaking changes for npm v12

#76

Post by luckman212 »

shimman wrote: post #64
tomnipotent wrote: post #58

Earlier quoted context omitted.

> they fired many staff engineers Would you rather the company went under after it ran out of money and had to fire everyone instead? Not to mention a quarter of the company was laid off the year before the acquisition.

Uhh, I'd expect the trillion dollar transnational corporation to do right by it's workers rather than rat fucking them to appease corporate do-nothing leeches if I'm being frank.

> I'd expect the trillion dollar transnational corporation to do right

you would? has any trillion dollar corporation ever?

Re: Upcoming breaking changes for npm v12

#77

Post by hedora »

garbagepatch wrote: post #73
cookiengineer wrote: post #67

What a pointless change. If you force every user to just use "--enable-unsecure-feature", guess what will happen? This is not about improving security. This is about shifting blame. A much better alternative would've been the introduction of sandboxes or simulation runs that would output which scripts and programs are running due to unpredictable dependencies. This way the user could check before the actual execution…

Most users don't need it. Having it on by default is a feature for malware writers not users. But to your point, Node has had permission flags for a while[0] but allows everything by default. Npm could use them to increase security even more. I just hope it doesn't take them another 10 years to change the default. [0] https://nodejs.org/api/permissions.html

Most packages don’t need it, but I imagine a large percentage of users do since most projects pull in an insane number of packages.

Still, “default off” is better. It would be nice if there were a lightweight way to fork upstream packages, and cache the native builds. It’d improve build times, make the build step more explicit / sandboxable and allow for easier binary builds for operating systems and processors that M$ treats as second class.

Re: Upcoming breaking changes for npm v12

#78

Post by hedora »

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.

“How do I get my security hardened CD pipeline to 2FA?”

Re: Upcoming breaking changes for npm v12

#79

Post by shimman »

luckman212 wrote: post #76
shimman wrote: post #64

Earlier quoted context omitted.

Uhh, I'd expect the trillion dollar transnational corporation to do right by it's workers rather than rat fucking them to appease corporate do-nothing leeches if I'm being frank.

> I'd expect the trillion dollar transnational corporation to do right you would? has any trillion dollar corporation ever?

No, and that's why we must destroy them. Figuratively then literally.

Re: Upcoming breaking changes for npm v12

#80

Post by tyre »

ok_dad wrote: post #56
w29UiIm2Xz wrote: post #24

Earlier quoted context omitted.

To be fair, the vibes (at the time) were that Microsoft has changed. Probably, in some way, a zero-interest rate phenomena.

Young people thought M$ was changing, the old folks knew it was just another cycle of embrace, extend, extinguish.

Young people were… right?

VS Code is open source. (Cursor is built on it!)

GitHub didn’t embrace, extend, extinguish git. You can git push to a different company (e.g. Gitlab) and you’ve migrated. The biggest problems with GitHub are scaling and availability, not lock-in.

Microsoft today is nothing like it was 30 or 20 years ago.

Fifteen years ago we were writing HTML and JavaScript specifically for Internet Explorer. Edge is built on Chromium.

Post reply on HN