Great read! But you mention that npm released npm trust in 11.10.0 for managing an allow-list but the docs you linked tell me how it allows you to set up trusted publishing as a maintainer.
It does not allow an enduser to set the packages that should be allowed to run scripts like eg. pnpm does.

One of the strengths of Homebrew, despite it being unpopular, is being willing to break backwards compatibility when necessary.

NPM’s unwillingness to do so reflects GitHub’s: both show excessive caution that harm both security and usability.

Yeah I guess so. npm just lets you do that manually if you are not using allow-scripts. I will do some more research on allow-scripts and talk to my colleagues. Maybe it’s the way to go for us!

And regarding pnpm: if I would be able to use it then allow-scripts wouldn’t be needed because pnpm gives me the functionality built in, right?

Regardless thank you for your work and your response and clarification!

It‘s just not so easy to propose to your colleagues: hey, we should not trust third party dependencies to run scripts so we have to restrict ourself and use another dependency to then allow specific dependencies again. But that’s probably the only way to go right now.

Thanks for the response and the clarification. I tried digging through discussions in the last weeks and months and your name popped up quite regularly so I was aware that you were trying to push for the Npm ecosystem to be more secure. I just couldn’t figure out why these proposals didn’t make it.

It feels wrong to me to have a third party dependency help me handle which third party dependencies are allowed to run scripts.
That should be sth that is included in npm. Or am I missing sth?

Do you know why this isn’t set in the npmx codebase? Or did I miss it? I haven’t found it in the pnpm-workspace.yaml

That sounds reasonable both from a maintainer perspective as well as a outside contributor. Having clear (contributing) guidelines is such a help for an outsider and it gives the maintainer a great handle to have a clear stance on closing (ai) issues.

The audience wasn’t just js devs so there was a varying level of awareness amongst the listeners. But I got the exact same feedback from some of them after the talk. Sth just clicked and you view your work with dependencies in a different light once you grasp some of the underlying risks

And to get back to your closing task: 1. I got to see the sun go down over the alps, 2. I got to play with my child and 3. I played a board game that I haven’t played in a long time. ❤️

Thank you for the post! Especially interrupting yourself and putting yourself on the spot could be a game changer for me. I will try that!

I just read this blog post by @joshuakgoldberg.com www.joshuakgoldberg.com/blog/please-... touching on an adjacent problem which was very well written. Would love to hear his input/ideas. It’s a dilemma for you as a maintainer.

Amazing! Thank for creating and sharing that ❤️

That is a leading question that I can and will not answer. Thank you for taking your time to discuss this matter. I will disengage now from this conversation. Have a good evening.

You missed a very important point. What happens in npmx‘s case is that you as the consumer are going to the npmx store, which has all the goods. And inside this store npmx decided to add customer notices to the products. You are free to go to another store without these customer notices.

That sounds like a reasonable change 👍

And I think the banner also is very open about the source of the information. It directly links to the important parts and gives additional context. It allows you as a reader to take action directly at the source if you choose to do so. So I’m sorry but I fail to see the point your trying to make.

This is specifically spoken from the perspective of a user of open source software and not from a maintainer perspective.
But I can also see benefits for the maintainer of a package: reducing the number of users that are not the target audience frees up time and bandwidth for the important issues

The banner shows exactly that. It tells me that I MIGHT not need it. And with that it educates me. It shows me sth I might have missed. And it could help reduce my attack surface by relying on less third party dependencies.

I know this feature and I really like it. Especially the case you presented. dotenv is an amazing project and it is still actively maintained. It still serves a purpose. But since node 20.6 it may not be necessary to depend on it anymore because there is a similar functionality built-in now.

npm-install | npm Docs Install a package

You can use them by adding

allow-git=none
min-release-age=7

to your .npmrc.
Look at the specifics of the configs in the docs: docs.npmjs.com/cli/v11/comm...

feat: add min-release-age by wraithgar · Pull Request #8965 · npm/cli This is a new config that is a way to populate the "before" config using a relative date integer. This deceptively small change was the result of a LOT of work to get to this point, prima...

npm v11.10 added the min-release-age config that allows you to delay the installation of newly released package versions. That was possibly with the —before flag but min-release-age lets you specify a relative number of days directly from your .npmrc (github.com/npm/cli/pull...)

PackageGate: 6 Zero-Days in JS Package Managers But NPM Won't Act We found 6 zero-day vulnerabilities in npm, pnpm, vlt, and Bun that bypass --ignore-scripts and lockfile protections. Five patched. npm closed the report.

npm v11.9 (shipped with the current lts version of node) introduced the allow-git flag that lets you block the installation of dependencies from git. This prevents an attack vector that allowed rce even with ignore-scripts present. Thanks to #koi.ai for there work www.koi.ai/blog/package...

A lot has happened in the last two minor releases of the npm cli that is important to know for people using it:

v11.9 : allow-git flag
v11.10: min-release-age

🧵

Ok I tried to create a post because I am really happy that I gave the talk and wanted to mention and thank npmx but I was nervous about how it sounds so I reworded it again and again and after posting it I noticed it sounds like a LinkedIn post now… 🫣 well. You got to start somewhere.

flag `git:` and `https:` dependencies · Issue #1084 · npmx-dev/npmx.dev They can be manipulated, see https://bsky.app/profile/dsherret.bsky.social/post/3me2bmgc32k2k including in transitive dependencies, all the way to the top.

There are things to improve (I for one would really like to see github.com/npmx-dev/npm... come to life) but even just right now in the canary state npmx.dev already helped me tremendously not only in regards to my presentation. I really appreciate the work of all the contributors ❤️

Screenshot of the npmx.dev website with the Nuxt package opened. It displays a banner saying „1 vulnerability in 1/506 packages“ and another one saying „2 deprecated dependencies“

When looking at a package I am informed about vulns and deprecated packages and can start my own journey of looking into the specifics and seeing if it affects me. It helps me to pay attention!

Especially when you are a new developer you don’t even think about the possible pitfalls.

This is why educating people is so important. I added @npmx.dev as an example because it does that in an unobtrusive way.

White male person presenting. He is pointing and looking at a screen which can’t be seen

Did my first talk regarding npm supply chain attacks at an internal developer conference last week. 🎉

My main talking point: Pay attention. It is so easy to mindlessly run an npm install without thinking about possible consequences. 🧵