I don't get it. How does this help with anything? You pull in a dependency to use it, right?
Well pulling some code is different than running a script on your machine
Upcoming breaking changes for npm v12
61–70 of 221 posts
Re: Upcoming breaking changes for npm v12
#62Looks good? But doesn't this just change the compromise window from first installation to first run?
I’m sure we’d all welcome your alternative and or superior proposals. Without that, this just comes across like unconstructive commentary. This moves the needle a little your proposals or the lack thereof don’t move it at all. So I’ll take this over nothing.
You'll notice that my comment was a question, you can tell by the presence of question marks at the end of the sentence.
Additionally, if a comment were to hypothetically point out an issue, that is valuable on its own. If someone reacts to a comment that points out an issue this defensively, it's a huge red flag.
Re: Upcoming breaking changes for npm v12
#63> The resulting allowlist is written to package.json Couldn’t this effectively result in the same process we get in pre-12 defaults?
It's unstated, but I'm willing to assume that only the root package.json is consulted to decide if these scripts are allowed. Otherwise, yes, this would not actually change anything.
Re: Upcoming breaking changes for npm v12
#64Earlier quoted context omitted.
MSFT acquisition of NPM was a massive shit show, they fired many staff engineers and people that were at github for quite a while. Top comment was a liar.
> 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.
Re: Upcoming breaking changes for npm v12
#65> allowScripts defaults to off Nice that they're following pnpm's lead on this after [checks watch]... 18 months?
Java‘s Maven never had them, never felt a need for them.
What is their purpose in JS land?
Re: Upcoming breaking changes for npm v12
#66> allowScripts defaults to off Nice that they're following pnpm's lead on this after [checks watch]... 18 months?
Java‘s Maven never had them, never felt a need for them. What is their purpose in JS land?
Off the top of my head the purposes I've seen for them:
- building native bindings (node-sass)
- asking for funding (core-js)
... Probably a few more but the native case is probably the biggest and the packages I'm using nowadays ship precompiled blobs in optionalDependencies. Install scripts seem to be out of favor.
Re: Upcoming breaking changes for npm v12
#67What 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, and maintain an allow list much easier. That could be done via an npm update && npm upgrade workflow where the update generates the list that the user has to manually confirm.
Heck, even a chroot would be an improvement, and they're almost pointless these days, considering how good malware got at escaping chroots.
Re: Upcoming breaking changes for npm v12
#68> allowScripts defaults to off Nice that they're following pnpm's lead on this after [checks watch]... 18 months?
Java‘s Maven never had them, never felt a need for them. What is their purpose in JS land?
native modules. nodejs can have native modules (written in C++, Rust, etc...). Projects usually ship prebuilt natives binaries (for each arch/OS/Nodejs ABI combination) hosted on GitHub Releases and download them automatically at installation time; fallback to build from source if not found. that's where scripts are used
the reason for not bundling all native binaries is becasue the no. of combinations are huge and it can make module size hundreds of MBs
Re: Upcoming breaking changes for npm v12
#69didn't know npm was owned by github.. well, that explains things...
Most people know this but the _real_ reason it explains things is that GitHub is owned by Microsoft. Oh, and Microsoft moved GitHub to Azure
To be fair, NPM sucked long before it got acquired by Github/Microsoft.
And to be fair 2: The other package repos also suck.
Re: Upcoming breaking changes for npm v12
#70Looks 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.
Don't forget about tests. That'll run code for every package that is imported. Yes, imported, because in JS importing means "run all the top level code in this file". So to continue exploiting you just place your malicious code in index.js instead of a postinstall script. Not as guaranteed to run but still very likely.