Rendered at 10:48:21 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
atraac 3 hours ago [-]
postinstall scripts should've been removed long time ago, it's the cancer of NPM packages. There's so many deeply nested, uncontrolled postinstalls that run randomly when you pull something it's insane, I don't know how someone at some point ever though that was a good idea.
VMG 47 minutes ago [-]
I must admit I don't really understand what the point of the post-install script concern is.
Usually, you run the actual packaged dependency code at some point anyway, and usually with the same permissions as the install process.
So all of these setup scripts (good or bad) can just move their entrypoint from npm to wherever the `import` or `require` happens.
It seems to me that this is a small stumbling block at best, unless the whole ecosystem moves to a deno-like sandboxed environment. Maybe that is the plan?
vbezhenar 7 minutes ago [-]
You can build application outside of container, but run it in container. I think that it is simpler workflow, than everything in container (when you actually need to develop it with IDE).
I didn't try devcontainers stuff, TBH. But that's how I often develop my apps.
That said, there are other attack surfaces for that approach. For example I'm not sure if I can trust LSP server not to execute application code. So keeping everything in a container or in a VM seems to be the only sane approach to work with code you don't trust.
rafaelmn 1 minutes ago [-]
>You can build application outside of container, but run it in container. I think that it is simpler workflow, than everything in container (when you actually need to develop it with IDE).
At this point I will not do any dev outside of a container - so many things can be supply chained in the OSS dev stack it's just not worth it, and once you get used to developing in containers it's actually a lot cleaner to move between hosts - you're essentially treating your client as a remote terminal.
If you're doing web dev work in this day an age SSH with tmux or some editor with SSH server support should be your dev setup.
Hopefully current hysteria will not result in some bs decisions like this.
homebrewer 2 hours ago [-]
Your own link says that a proper package manager (e.g. pnpm) supports this out of the box.
If there are other use cases that really need post-install scripts, you can whitelist just those in pnpm. In projects I'm working with, there are often zero post-install scripts that must be enabled for everything to work properly, and it's usually from poorly cobbled packages that use them to download prebuilt binaries (well written packages, like biome or tsgo, use per-architecture subpackages).
You enable just one or two of those, and block everything else.
philipwhiuk 2 hours ago [-]
The entire use-case of that package is a security nightmare.
gear54rus 2 hours ago [-]
Then don't use it. Just don't presume to tell me if I can or can't.
dgellow 2 hours ago [-]
Given that has an impact over the whole industry, I will for sure tell you that patching on install SHOULD NOT be a thing. Up to you to run your own post install script yourself
gear54rus 2 hours ago [-]
It absolutely should and maybe I'll run and advertise a fork that will behave properly. Yay open-source.
ramon156 1 hours ago [-]
Elaborate on the "behave properly". What is properly here?
port11 48 minutes ago [-]
You’re free to allow scripts as per the linked docs for NPM 12. But the vast majority of us will appreciate the reduced attack surface.
tuckwat 11 hours ago [-]
I bet there have been a hundred different discussions about this inside of NPM since it was disclosed 10 years ago. With Shai Halud it's gotten too big to ignore.
Eji1700 5 hours ago [-]
I do love that javascript's history is basically just coder mentality distilled. "oh yeah we'll fix that shortly" is almost always "oh fuck now we have to"
1 minutes ago [-]
port11 50 minutes ago [-]
I chuckled, but this is more about the history of NPM.
In retrospect, allowing an ES consortium seat (Microsoft) to own the largest package repo for the language… might have been a bad idea? Google is one of the worst members of the language board, but Microsoft might be a close second.
Given their ownership of GitHub came with a general community unease, perhaps it’s not surprising that NPM isn’t dating much better. 16 years later we are getting good security controls. Okay.
I’m happy with Deno for most of my needs!
appplication 6 hours ago [-]
Great, now it’s python’s turn next
karakanb 12 hours ago [-]
It is not obvious from the post but it seems like the allow list for the scripts supports whitelisting packages instead of a global setting. This should make it easier to maintain org-wise rules to allow scripts only for specific packages.
Is there a linter that could be used for scenarios like this to prevent unsafe default on package manager config?
philipwhiuk 2 hours ago [-]
grep?
alexghr 5 hours ago [-]
Are the current LTS node versions (iirc 22, 24, 26) going to update the bundled npm to v12 to benefit from these security fixes? All come with npm v11 now
jamiem 5 hours ago [-]
Major npm version bumps have landed mid-stream for node in the past: v18.19.0[1] and v20.10.0[2] bumped npm 9 to 10.
They are changes in defaults, which could be construed as a security posture change, but the security fix is in everyone's hands. Just set proper defaults, as per article, and done.
I think the best part of this change, is that the default change will mean that lots of new DEVs just running an install, will see instant breakage with annoying packages that presume these settings are on. It should force people to stop expecting scripts to be runnable, for example.
partsch 4 hours ago [-]
I wonder if there are still reasons to use yarn? Has yarn also implemented safeguards to protect against supply chain attacks? Until now, I only knew about pnpm. It’s great that npm has followed up.
homebrewer 2 hours ago [-]
One distinguishing feature is their optional install strategy: running packages directly from compressed archives instead of unpacking them into node_modules.
Very similar to using .jar's in Java instead of directory trees of .class files.
It's somewhat hacky though, and editor/tool support varies.
- since there are far fewer small files, it can be faster especially on Windows if you're forced to work on it for some reason
- the archives can be stored into the git repository (through git-lfs or friends), removing dependency on the internet and the package registry
rozenmd 3 hours ago [-]
I worked on a project that used yarn from the early days all the way up to v3, it's slow as hell, but it works. They also have the supply chain protections.
Eventually we snapped and migrated to pnpm. Installs (both in CI and on local dev machines) are significantly faster. Turned out to be about a day's work to migrate with an LLM's help.
arcatek 50 minutes ago [-]
I don't doubt that 3.x probably has worst perfs (it's almost two years old now), but just to clarify we closely track performances and Yarn and pnpm and pretty much on similar level:
Of course. Modern Yarn releases (4.x) are deterministic to a fault and you can rely on it to have a consistent behavior across your whole team. As for feature-wise I'd say it's a lot of small details that together add up once you grow used to them.
The next major release will keep pushing in that direction with both better performances and features we couldn't implement until now due to their reliance on said perfs improvements.
Disclaimer: I'm the Yarn lead maintainer.
tuwtuwtuwtuw 17 minutes ago [-]
Deterministic to a fault unless you mix Windows and Linux.
> Microsoft doesn’t do everything right but the GitHub acquisition has honestly gone better than I ever expected. Rather than forcing GitHub to adopt Microsoft centric policies, Microsoft has adopted more GitHub stuff, especially from a product POV. GitHub still runs as a separate company (different logins and health care and hiring systems) with its own policies and point of view.
> ...
w29UiIm2Xz 12 hours ago [-]
To be fair, the vibes (at the time) were that Microsoft has changed. Probably, in some way, a zero-interest rate phenomena.
ok_dad 9 hours ago [-]
Young people thought M$ was changing, the old folks knew it was just another cycle of embrace, extend, extinguish.
tyre 6 hours ago [-]
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.
pietervdvn 3 hours ago [-]
VScode might be open source (to a degree), but the levers of control are on a different location. See https://ghuntley.com/fracture/ for an excellent blog on it.
beezlewax 6 hours ago [-]
Do microsoft own git now?
I don't think so
jraph 3 hours ago [-]
> VS Code is open source
Open core at best. It's proprietary software built on top of an open source base. The remote coding feature is proprietary and you need to run proprietary software on the remote server / container to use it. People maintaining forks (like Codium and the Theia IDE) are not allowed to use VS Code's marketplace. Many of their flagship VS Code extensions are proprietary. Why would they do this if they believed in open source?
The distinction is quite important. VS Code aims to get control of the development process of those who are not using Visual Studio. That's the only reason why VS Code exists. VS Code is not a gift no strings attached.
By the way the title of https://code.visualstudio.com/ is a lie that says "The open source AI code editor". Three lines under, there's "By using VS Code, you agree to its license and privacy statement.". The license is https://code.visualstudio.com/license, which is very much like your usual horrible Microsoft EULA, including tracking and forbidden reverse engineering, decompiling or disassembling. Really, the only thing missing there is the license key field at first run.
GitHub is still proprietary SaaS also aiming to control the whole open source ecosystem. With GitHub, a big chunk of the open source (and free software! Which is even sadder) world relies on proprietary infra. That's as close as Extinguish as you can get (it's just that git is not the thing that's Extinguished). GitHub is actually a pretty good example of lock-in, see what other commenters wrote on this.
30 years later, Microsoft, still the same lying company trying to control its users and the world with proprietary software. With the twist that they try a bit harder to look cool and open source (since the moment they realized open source wasn't going to disappear, not before). They really are not, especially for end-user facing software, including when the end-users are developers.
The only thing that dramatically changed is that they don't publicly claim Linux is cancer anymore, and that's probably because they are coerced into dealing with Linux. Exactly like the Web against their failed attempt to privatize it with MSN (MicroSoft Network) (the current MSN news frontpage and the memory of their messenger are only shadows of the original ambitions behind MSN).
At least the stability and consistency is comforting… or not.
Don't fall for their open washing. They just play along and attempt to get control on what they didn't manage to extinguish. Only forced changes happened, the spirit seems intact.
z33k 6 hours ago [-]
Good luck migrating the ”forge” part with the ”git” part. Your github org settings, pull requests, rulesets, CI/CD pipelines, containers, copilot...
The lock-in always comes from the ”forge” part, never the ”git” part.
albedoa 6 hours ago [-]
> GitHub didn’t embrace, extend, extinguish git.
Literally nobody has said that it did? This is a wild strawman. Who are you trying to fool.
pjmlp 5 hours ago [-]
Old folks are also aware that applies to every single big tech company that actually sponsors the FOSS tools many don't want to pay anything back, while expecting to be paid themselves.
Old folks also remember the days when it was possible to make a living out of selling software tools.
hnfong 4 hours ago [-]
The ruthlessness of the Microsoft that we remember was probably due to influence from Bill Gates.
He is famous for hyper-competitiveness and strong desire to win at all costs.
Dylan16807 8 hours ago [-]
Microsoft has been causing a lot of problems lately but I completely disagree that it fits the pattern of "embrace, extend, extinguish".
Forgeties79 4 hours ago [-]
Remember when folks thought Phil Spencer was gonna right the Xbox ship lol
shimman 11 hours ago [-]
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.
_pythonlover_ 5 hours ago [-]
I was part of the npm team at GitHub. They laid off almost the entire team to focus on AI (CTO literally told us on the layoff announcement call that they're doing this to focus on Copilot)
tomnipotent 9 hours ago [-]
> 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.
7bit 4 hours ago [-]
Was that the case? Can you provide sources to your claims and provide a foundation to your theories?
Year before the MSFT takeover. No idea about their actual financials but they were definitely shedding headcount pre 2020, including kicking people for trying to unionise.
7bit 31 minutes ago [-]
Nothing in there suggests that this was done to save the company from bankruptcy, which was the wild claim.
tomnipotent 4 hours ago [-]
It's literally a Google search away. If you had the time to write this comment, you had more than enough time to do the search.
7bit 30 minutes ago [-]
Not my job to proof the wild claim that the layoffs were to save the company from bankruptcy .
shimman 8 hours ago [-]
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.
luckman212 7 hours ago [-]
> I'd expect the trillion dollar transnational corporation to do right
you would? has any trillion dollar corporation ever?
shimman 7 hours ago [-]
No, and that's why we must destroy them. Figuratively then literally.
altmanaltman 6 hours ago [-]
Destroy what exactly? And replace with what?
Dr4kn 4 hours ago [-]
With smaller companies that can't yield global power. It would be better if cloud, office and OS would be separate. Then you wouldn't get shuffed OneDrive into the OS. It's also better for competition if the playing field is equal and one solution isn't the only one that can deeply integrate. Build APIs or don't do it.
Forgeties79 4 hours ago [-]
Can y’all just state your opinions on these things rather than constantly asking bait-y questions?
altmanaltman 6 hours ago [-]
it was all good until AI entered the chat
ralph84 11 hours ago [-]
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.
materielle 11 hours ago [-]
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.
monster_truck 10 hours ago [-]
And additionally was it truly worth buying if this is what we've ended up with? Some things should be allowed to fail
arcatek 54 minutes ago [-]
Eh, easy to say. Remember how Sourceforge started shipping ads in binaries people downloaded? If you think failing was the worst scenario, you lack imagination.
joeyhage 13 hours ago [-]
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
amitport 8 hours ago [-]
To be fair, NPM sucked long before it got acquired by Github/Microsoft.
And to be fair 2: The other package repos also suck.
creesch 48 minutes ago [-]
> And to be fair 2: The other package repos also suck.
If you mean other languages, then yeah a lot of similar issues and weirdness there as well. Maven dependencies in any complex project are a "fun" challenge as well.
Though the sort of recurring supply chain attacks you see within the npm ecosystem is something I haven't seen elsewhere to this degree.
jbverschoor 6 hours ago [-]
Yeah, but the azure supply chain attack explains why all of a sudden they can make this change.
It seems that if you want to get something important changed in npm, you simply need exploit some of its short comings against Microsoft instead of discussing why it’s necessary.
tempay 6 hours ago [-]
To be fair, the entire problem space sucks and I’m not sure it’s possible not to.
domh 5 hours ago [-]
I knew it was owned by github, but this is the first time I've personally seen the release notes on github's blog instead of npm's.
BowBun 13 hours ago [-]
yes, since 2020
beart 9 hours ago [-]
Does the allow list in package.json pin to the package version, or only to the package name?
thatmf 11 hours ago [-]
> allowScripts defaults to off
Nice that they're following pnpm's lead on this after [checks watch]... 18 months?
MrBuddyCasino 8 hours ago [-]
Java‘s Maven never had them, never felt a need for them.
What is their purpose in JS land?
tuananh 8 hours ago [-]
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
sroussey 5 hours ago [-]
Having a non-script method of downloading the right native binary would be a good next step.
2 hours ago [-]
MrBuddyCasino 4 hours ago [-]
Yeah this seems manageable.
vardump 2 hours ago [-]
There should be a path for local building as well. Node.js is being used on a lot of embedded systems. I’d imagine there are also lots of other reasons for local builds.
tuananh 1 hours ago [-]
there's fallback to build from source but it would require the builder to have all the toolchain installed (whatever the library is using: could be gcc, python, rustc....)
dgoldstein0 8 hours ago [-]
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.
ComputerGuru 12 hours ago [-]
My big question as an OSS dev distributing some precompiled binaries via npm for easy installation: does allowScripts also default to disabled when directly installing a package (globally or otherwise)?
jamiem 5 hours ago [-]
Yes, all install scripts will be disabled by default regardless of if they are from direct or transitive dependencies.
But if you're already following the os + cpu + optionalDependencies model to distribute your precompiled binaries you should be fine.
efortis 13 hours ago [-]
this release fixes a vulnerability reported 10 years ago
Now all the malware can move from the install script to the module itself where it will inevitably still be run
z3t4 1 hours ago [-]
npmjs.org is a joke at this point. I guess their support is run by LLM because you can just write to them and they will transfer ownership of any module nilly willy.
tobyhinloopen 1 hours ago [-]
That’s a bold claim to randomly write without any supporting sources
z3t4 47 minutes ago [-]
I've got an example and submitted it via bug bounty channel, but they classified it as "social engineering".
chimpanzee2 4 hours ago [-]
Cool, but I default to pnpm these days anyway.
TZubiri 13 hours ago [-]
Looks good? But doesn't this just change the compromise window from first installation to first run?
semiquaver 13 hours ago [-]
Ok? Not sure what a package manager can do about the fact that eventually you want to run the things you install.
frabcus 4 hours ago [-]
Have any kind of provenance. eg like Debian has for 30 years. Key signing in person etc
tpetry 2 hours ago [-]
That has also been implemented recently. With staged publishing the author must verify a new release with 2FA so automated attacks dont work anymore. Some human in the loop must verify a release.
grassfedgeek 12 hours ago [-]
"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.
Rohansi 8 hours ago [-]
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.
pjio 6 hours ago [-]
> So for that entire class of packages this change makes them safe.
This is misleading. The change addresses one important attack vector. But if one runs the application directly on the host for development, if the package is imported like pointed out in the other comments or the package intends to steal user credentials from production, it is far from "being safe". Safer, but still needs scrutiny.
6 hours ago [-]
tabwidth 11 hours ago [-]
Build tooling still runs though. Your bundler plugin or PostCSS transform gets full fs access at build time, nobody's auditing that.
TZubiri 11 hours ago [-]
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.
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.
WatchDog 11 hours ago [-]
"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.
TZubiri 11 hours ago [-]
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:
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
christophilus 13 hours ago [-]
Better than nothing. That’s the same problem every package manager has.
insanitybit 12 hours ago [-]
Yes, but that's actually a huge win. I can't know what a package needs to do at install time - the dev knows that. But I know what my tests and program need to do at runtime because it's my job to understand those things.
The dev has to be responsible for ensuring that their build scripts are safe, I need to be responsible for ensuring that my runtime is safe.
It'd be great to have more tools for untrusting libraries (iframes are awesome for this on the frontend) but this is still a massive win.
tentacleuno 3 hours ago [-]
v8 does have a sandbox feature for running untrusted scripts, and it's quite good. There's also Node's VM module.
Someone1234 13 hours ago [-]
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.
spartanatreyu 11 hours ago [-]
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/
- My bundler wants read and write access to my file system?
- 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...
- Oh what's this? An updated dependency I've been using for 6 months suddenly asking for access to my .env file, and asking to run curl in a separate process? How about "no". Why would a simple DOM utility dependency be asking for those permissions? Ah, looks like it was part of a credential stealing supply chain attack. Glad I wasn't using node.
---
Addendum: Node now has a permission system, but it's broken by design so it's useless.
tpetry 2 hours ago [-]
Can you clarify why the node permission system is broken but the deno one works? For an outsider like me both look like the same.
TZubiri 9 hours ago [-]
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.
mschuster91 12 hours ago [-]
An idea might be to not just pin "package xyz allowed", but "package xyz postinstall allowed with hash <1234>".
Together with a lockfile that does achieve "package xyz postinstall allowed with hash <1234>"
philipwhiuk 2 hours ago [-]
> On balance, it’s npm’s belief that the utility of having installation scripts is greater than the risk of worms. This is a tradeoff that we will continue to evaluate.
They chose...poorly
Zopieux 12 hours ago [-]
Eh, that only took a few dozen actively exploited supply-chain vulns in the span of two years!
dawnerd 12 hours ago [-]
Only took Microsoft themselves getting hit with it for things to change.
thrdbndndn 10 hours ago [-]
How do you allow scripts for tools installed globally?
jamiem 5 hours ago [-]
Either pass the --allow-scripts=<pkg> flag with npx or npm install -g, or set allow-scripts=<pkg> in .npmrc
jbverschoor 6 hours ago [-]
And when will we get rid of the vendored node_modules, and make it read only?
heldrida 12 hours ago [-]
> The resulting allowlist is written to package.json
Couldn’t this effectively result in the same process we get in pre-12 defaults?
CGamesPlay 9 hours ago [-]
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.
heldrida 2 hours ago [-]
Thanks for the sanity check!
Had a quick read on my mobile, and that was my first impression.
Guess its more of a way to make the maintainers accountable instead of making npm reputation the main focus.
Pxtl 10 hours ago [-]
I would've assumed lockfile-by-default. We're still going with auto-updating?
jbreckmckye 10 hours ago [-]
You do get a lockfile by default
retardedsecguy 10 hours ago [-]
npm is basically pnpm now
cute_boi 9 hours ago [-]
Except pnpm is written in Rust and is very fast, saves disk and has much more advantage.
uasi 2 hours ago [-]
> pnpm is written in Rust
Not just yet. The Rust rewrite of the installation engine is still experimental and available as an opt-in preview[0].
They should have added a 1-day age limit by default, so security scanners have some time.
KolmogorovComp 12 hours ago [-]
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.
therealmarv 11 hours ago [-]
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.
doctorpangloss 10 hours ago [-]
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?
tuwtuwtuwtuw 7 minutes ago [-]
Yes, you need to check security issues reported for packages and then take a decision. What is the alternative?
therealmarv 2 hours ago [-]
[dead]
jnwatson 12 hours ago [-]
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.
b112 4 hours ago [-]
While I think this may be true, what validation do you have on this point?
Have you rolled the numbers, vs all of the high-pri security updates that will be missed on day one, and exploited?
What is really needed is simply more nuance. I agree the delay can help, but honestly the entire ecosystem is broken. There shouldn't be a single thing installed, without someone having an eyes-on. That's how this is fixed.
Distros aren't perfect, but they handle this a load better. And this really runs to the problem, people want "new new new", yet often have very little real reason to want it. 99% of npm packages could be 5 years old, and no one would care.
But outside of that, npm could operate like a distro, but with more of a Debian unstable -> testing method, where it typically takes a few days for this migration to happen.
My point is, the fix isn't publishing by default, then hoping to catch. The fix is that nothing gets published, without a QA/validation step. Of course, that takes money. There is naturally, a super easy fix for that.
The code stays open source. The licensing stays <insert whatever by author>. However?
The ToS for using any or all of the npm architecture is if you're a company, you pay. If you neglect to pay, eg you don't register as a corporate entity, set up and account, and pay per use, then as per ToS the licensing is invalid, and you're fined via a copyright infringement. And yes, this would mean all npm packages would have an altered licensing model, basically with this tacked on.
Is what I'm saying perfect? Nope. Yet it's the general path which should be taken. And frankly, with the way things are going, this level of audit would allow for staff also categorize licenses, ensure accurate template files, and so on.
And some of this is the perfect use of an LLM. Not to do the work, but to flag with human review.
--
This ecosystem is done. Its model is broken. The concept of downloading random stuff without auditing in any way, is broken. The industry will be moving away, is starting to move away, and is having to move away.
So... how can this survive with that concept?
If one doesn't like my proposal above, then they should provide an alterative which allows:
* companies to have validate of licensing
* audits which validate change is not untoward
alexdns 11 hours ago [-]
so this parameter can be passed by the attackers also thus making your point pointless
gbear605 11 hours ago [-]
The idea of the parameter is stopping the attackers from getting on your system in the first place
therealmarv 11 hours ago [-]
that parameter cannot be set by a package, you only can set it
woodruffw 8 hours ago [-]
I think you want both of these things. Realistically we're not at a point yet where all MFA credentials are phishing resistant.
hedora 7 hours ago [-]
“How do I get my security hardened CD pipeline to 2FA?”
geophph 11 hours ago [-]
The maintainer of pnpm mentioned this on the pod rocket podcast recently. Based on recent npm exploits they decided to (and based on a poll they did most users agreed) set to 1 day by default in v11. Can always choose to change it if you desire.
The changelog design has been like that since last year,[0] which predates today's slop design of small caps and monospace text (probably because they both are based on the same design trend). A year ago, vibe coded websites leaned more on sans serif and gradient text.
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.
woodruffw 8 hours ago [-]
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.
garbagepatch 8 hours ago [-]
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.
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.
recursive 8 hours ago [-]
I'm not going to get forced.
SCLeo 10 hours ago [-]
I don't get it. How does this help with anything? You pull in a dependency to use it, right?
dlopes7 9 hours ago [-]
Well pulling some code is different than running a script on your machine
zarzavat 10 hours ago [-]
There's an easy way to stop most supply chain attacks:
1. Publishing users must approve each and every release from a smartphone app.
2. Publishing users must provide verified government ID.
The first step prevents the types of attacks where an attacker gets control of a maintainer's computer and publishes a new release.
The second step discourages attacks where a user tries to get a malicious package used by others.
When combined with the security features that already exist, e.g. delays and automatic scanning, it would make it considerably harder to pull off a successful attack.
ifwinterco 5 hours ago [-]
Issue is this is such a pain (and shuts out a large percentage of the world population) that you'll inevitably get a parallel ecosystem of packages without these onerous controls that everyone would end up using.
I don't know how to square the circle but any variation of "make it safer but really painful and difficult for anyone to publish a package" has this problem
Usually, you run the actual packaged dependency code at some point anyway, and usually with the same permissions as the install process.
So all of these setup scripts (good or bad) can just move their entrypoint from npm to wherever the `import` or `require` happens.
It seems to me that this is a small stumbling block at best, unless the whole ecosystem moves to a deno-like sandboxed environment. Maybe that is the plan?
I didn't try devcontainers stuff, TBH. But that's how I often develop my apps.
That said, there are other attack surfaces for that approach. For example I'm not sure if I can trust LSP server not to execute application code. So keeping everything in a container or in a VM seems to be the only sane approach to work with code you don't trust.
At this point I will not do any dev outside of a container - so many things can be supply chained in the OSS dev stack it's just not worth it, and once you get used to developing in containers it's actually a lot cleaner to move between hosts - you're essentially treating your client as a remote terminal.
If you're doing web dev work in this day an age SSH with tmux or some editor with SSH server support should be your dev setup.
Hopefully current hysteria will not result in some bs decisions like this.
If there are other use cases that really need post-install scripts, you can whitelist just those in pnpm. In projects I'm working with, there are often zero post-install scripts that must be enabled for everything to work properly, and it's usually from poorly cobbled packages that use them to download prebuilt binaries (well written packages, like biome or tsgo, use per-architecture subpackages).
You enable just one or two of those, and block everything else.
In retrospect, allowing an ES consortium seat (Microsoft) to own the largest package repo for the language… might have been a bad idea? Google is one of the worst members of the language board, but Microsoft might be a close second.
Given their ownership of GitHub came with a general community unease, perhaps it’s not surprising that NPM isn’t dating much better. 16 years later we are getting good security controls. Okay.
I’m happy with Deno for most of my needs!
Is there a linter that could be used for scenarios like this to prevent unsafe default on package manager config?
[1]: https://nodejs.org/en/blog/release/v18.19.0#npm-updated-to-v... [2]: https://nodejs.org/en/blog/release/v20.10.0
I think the best part of this change, is that the default change will mean that lots of new DEVs just running an install, will see instant breakage with annoying packages that presume these settings are on. It should force people to stop expecting scripts to be runnable, for example.
https://yarnpkg.com/features/pnp
Very similar to using .jar's in Java instead of directory trees of .class files.
It's somewhat hacky though, and editor/tool support varies.
- since there are far fewer small files, it can be faster especially on Windows if you're forced to work on it for some reason
- the archives can be stored into the git repository (through git-lfs or friends), removing dependency on the internet and the package registry
Eventually we snapped and migrated to pnpm. Installs (both in CI and on local dev machines) are significantly faster. Turned out to be about a day's work to migrate with an LLM's help.
https://p.datadoghq.eu/sb/d2wdprp9uki7gfks-c562c42f4dfd0ade4...
The next major release will keep pushing in that direction with both better performances and features we couldn't implement until now due to their reliance on said perfs improvements.
Disclaimer: I'm the Yarn lead maintainer.
https://github.com/yarnpkg/berry/issues/6105
Some of it aged... interesting.
Top comment:
> Microsoft doesn’t do everything right but the GitHub acquisition has honestly gone better than I ever expected. Rather than forcing GitHub to adopt Microsoft centric policies, Microsoft has adopted more GitHub stuff, especially from a product POV. GitHub still runs as a separate company (different logins and health care and hiring systems) with its own policies and point of view.
> ...
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.
I don't think so
Open core at best. It's proprietary software built on top of an open source base. The remote coding feature is proprietary and you need to run proprietary software on the remote server / container to use it. People maintaining forks (like Codium and the Theia IDE) are not allowed to use VS Code's marketplace. Many of their flagship VS Code extensions are proprietary. Why would they do this if they believed in open source?
The distinction is quite important. VS Code aims to get control of the development process of those who are not using Visual Studio. That's the only reason why VS Code exists. VS Code is not a gift no strings attached.
By the way the title of https://code.visualstudio.com/ is a lie that says "The open source AI code editor". Three lines under, there's "By using VS Code, you agree to its license and privacy statement.". The license is https://code.visualstudio.com/license, which is very much like your usual horrible Microsoft EULA, including tracking and forbidden reverse engineering, decompiling or disassembling. Really, the only thing missing there is the license key field at first run.
GitHub is still proprietary SaaS also aiming to control the whole open source ecosystem. With GitHub, a big chunk of the open source (and free software! Which is even sadder) world relies on proprietary infra. That's as close as Extinguish as you can get (it's just that git is not the thing that's Extinguished). GitHub is actually a pretty good example of lock-in, see what other commenters wrote on this.
30 years later, Microsoft, still the same lying company trying to control its users and the world with proprietary software. With the twist that they try a bit harder to look cool and open source (since the moment they realized open source wasn't going to disappear, not before). They really are not, especially for end-user facing software, including when the end-users are developers.
The only thing that dramatically changed is that they don't publicly claim Linux is cancer anymore, and that's probably because they are coerced into dealing with Linux. Exactly like the Web against their failed attempt to privatize it with MSN (MicroSoft Network) (the current MSN news frontpage and the memory of their messenger are only shadows of the original ambitions behind MSN).
At least the stability and consistency is comforting… or not.
Don't fall for their open washing. They just play along and attempt to get control on what they didn't manage to extinguish. Only forced changes happened, the spirit seems intact.
Literally nobody has said that it did? This is a wild strawman. Who are you trying to fool.
Old folks also remember the days when it was possible to make a living out of selling software tools.
He is famous for hyper-competitiveness and strong desire to win at all costs.
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.
Year before the MSFT takeover. No idea about their actual financials but they were definitely shedding headcount pre 2020, including kicking people for trying to unionise.
you would? has any trillion dollar corporation ever?
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.
And to be fair 2: The other package repos also suck.
If you mean other languages, then yeah a lot of similar issues and weirdness there as well. Maven dependencies in any complex project are a "fun" challenge as well.
Though the sort of recurring supply chain attacks you see within the npm ecosystem is something I haven't seen elsewhere to this degree.
It seems that if you want to get something important changed in npm, you simply need exploit some of its short comings against Microsoft instead of discussing why it’s necessary.
Nice that they're following pnpm's lead on this after [checks watch]... 18 months?
What is their purpose in JS land?
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
... 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.
But if you're already following the os + cpu + optionalDependencies model to distribute your precompiled binaries you should be fine.
https://www.kb.cert.org/vuls/id/319816
This is misleading. The change addresses one important attack vector. But if one runs the application directly on the host for development, if the package is imported like pointed out in the other comments or the package intends to steal user credentials from production, it is far from "being safe". Safer, but still needs scrutiny.
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.
There is plenty of malicious stuff you can do from the browser.
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
The dev has to be responsible for ensuring that their build scripts are safe, I need to be responsible for ensuring that my runtime is safe.
It'd be great to have more tools for untrusting libraries (iframes are awesome for this on the frontend) but this is still a massive win.
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.
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?
- My bundler wants read and write access to my file system? - Oh what's this? An updated dependency I've been using for 6 months suddenly asking for access to my .env file, and asking to run curl in a separate process? How about "no". Why would a simple DOM utility dependency be asking for those permissions? Ah, looks like it was part of a credential stealing supply chain attack. Glad I wasn't using node.---
Addendum: Node now has a permission system, but it's broken by design so it's useless.
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.
Together with a lockfile that does achieve "package xyz postinstall allowed with hash <1234>"
They chose...poorly
Couldn’t this effectively result in the same process we get in pre-12 defaults?
Had a quick read on my mobile, and that was my first impression.
Guess its more of a way to make the maintainers accountable instead of making npm reputation the main focus.
Not just yet. The Rust rewrite of the installation engine is still experimental and available as an opt-in preview[0].
[0] https://github.com/pnpm/pnpm/releases/tag/v11.2.2
A better safety net would be to require active 2FA proof for every package update.
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.
(You write something)
So then you have to check every package's updates and decide if you update, yes?
Have you rolled the numbers, vs all of the high-pri security updates that will be missed on day one, and exploited?
What is really needed is simply more nuance. I agree the delay can help, but honestly the entire ecosystem is broken. There shouldn't be a single thing installed, without someone having an eyes-on. That's how this is fixed.
Distros aren't perfect, but they handle this a load better. And this really runs to the problem, people want "new new new", yet often have very little real reason to want it. 99% of npm packages could be 5 years old, and no one would care.
But outside of that, npm could operate like a distro, but with more of a Debian unstable -> testing method, where it typically takes a few days for this migration to happen.
My point is, the fix isn't publishing by default, then hoping to catch. The fix is that nothing gets published, without a QA/validation step. Of course, that takes money. There is naturally, a super easy fix for that.
The code stays open source. The licensing stays <insert whatever by author>. However?
The ToS for using any or all of the npm architecture is if you're a company, you pay. If you neglect to pay, eg you don't register as a corporate entity, set up and account, and pay per use, then as per ToS the licensing is invalid, and you're fined via a copyright infringement. And yes, this would mean all npm packages would have an altered licensing model, basically with this tacked on.
Is what I'm saying perfect? Nope. Yet it's the general path which should be taken. And frankly, with the way things are going, this level of audit would allow for staff also categorize licenses, ensure accurate template files, and so on.
And some of this is the perfect use of an LLM. Not to do the work, but to flag with human review.
--
This ecosystem is done. Its model is broken. The concept of downloading random stuff without auditing in any way, is broken. The industry will be moving away, is starting to move away, and is having to move away.
So... how can this survive with that concept?
If one doesn't like my proposal above, then they should provide an alterative which allows:
* companies to have validate of licensing * audits which validate change is not untoward
https://red.anthropic.com/2026/n-days/
So that is a poor bandaid to use now. Maybe instead validate things before, and have more of a cathedral and human reputation system.
Finally.
"retired" is probably a followup to functionality that was "deprecated".
I agree "breaking" would be clearer
It's a holdover from previous posts where there were more clearly defined deprecations.
but yes, in this case it's more of a behavioural change of defaults, so they just picked the closest vaguely mapped retired/deprecations tag.
1: https://github.blog/changelog/?type=deprecations
[0]: https://github.blog/changelog/2025-05-05-improvements-to-cha...
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.
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.
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
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.
1. Publishing users must approve each and every release from a smartphone app.
2. Publishing users must provide verified government ID.
The first step prevents the types of attacks where an attacker gets control of a maintainer's computer and publishes a new release.
The second step discourages attacks where a user tries to get a malicious package used by others.
When combined with the security features that already exist, e.g. delays and automatic scanning, it would make it considerably harder to pull off a successful attack.
I don't know how to square the circle but any variation of "make it safer but really painful and difficult for anyone to publish a package" has this problem