The "aw geez, enough is enough" release.
Finally.
Upcoming breaking changes for npm v12
31–40 of 221 posts
Re: Upcoming breaking changes for npm v12
#32Looks 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.
Build tooling still runs though. Your bundler plugin or PostCSS transform gets full fs access at build time, nobody's auditing that.
Re: Upcoming breaking changes for npm v12
#33Looks 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.
"First run" certainly exists in web apps, it's just running JS in a browser rather than a shell script on a developer or CI machine.
There is plenty of malicious stuff you can do from the browser.
Re: Upcoming breaking changes for npm v12
#34> allowScripts defaults to off
Nice that they're following pnpm's lead on this after [checks watch]... 18 months?
Re: Upcoming breaking changes for npm v12
#35Looks 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.
We already have alternative and superior proposals, it's called Deno.
It's node + npm compatible and its permission system locks everything down by default.
If you know ahead of time, you can turn on which permissions something is supposed to have in the config file.
Or you can just not use a config file at all. Anytime it needs a permission: it asks you what it wants. You can say yes or no, and those are saved in the config file for next time. If you say no, the script throws an error where it tried to access something it didn't have permission for.
---
Example:
- My linter wants access to my file system?
- You can have read access to ./src/ts/
- You can have read access to ./src/ts and write access to ./build-output
- Huh, what's that? The bundler was trying to both read and write a file in ./src/ts?
- We don't want input files getting overwritten, that's a recipe for hard-to-diagnose race conditions. Looks like the permission system did more than just keep things secure, it's like a type system for IO.
- Oh, look at that, there was a very subtle bundler misconfig, let me fix that now. How long would that have existed if we didn't use deno...
---
Addendum: Node now has a permission system, but it's broken by design so it's useless.
Re: Upcoming breaking changes for npm v12
#36Earlier 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
The idea of the parameter is stopping the attackers from getting on your system in the first place
Re: Upcoming breaking changes for npm v12
#37Earlier quoted context omitted.
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.
An idea might be to not just pin "package xyz allowed", but "package xyz postinstall allowed with hash ".
The default behavior for the automated "add everything existing to the allowlist" is to include the specific version: https://docs.npmjs.com/cli/v11/using-npm/config#allow-script...
Together with a lockfile that does achieve "package xyz postinstall allowed with hash "
Re: Upcoming breaking changes for npm v12
#38didn'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.
Re: Upcoming breaking changes for npm v12
#39Earlier quoted context omitted.
Breaking changes have had that tag for ages
Really? Retired? What does that even mean in this context, why not "breaking" or something else that suggests breaking change?
> Retired? What does that even mean in this context
"retired" is probably a followup to functionality that was "deprecated".
I agree "breaking" would be clearer