Post

How to bypass minimum dependency/release age: 1. Publish an npm package with an unpinned git dependency. 2. Get usage and wait many months. 3. Push a malicious commit to the git dependency's repo.

How to recreate leftpad: 1. Publish an npm package with a git dependency. 2. Get usage and wait many months. 3. Delete the repo.

Both of these are also possible using https dependencies in an npm package. Worst part is in some cases the package wouldn't easily be able to be taken down. npm, pnpm, and bun all happily install this kind of stuff—`deno install` errors.

Several popular npm packages transitively have this problem, including a recent popular one. It's only a matter of time before someone takes advantage of this.

You can lint against it www.npmjs.com/package/@lav...

And disable install scripts except the ones you really explicitly want www.npmjs.com/package/@lav...

It's good there's the option, but most people won't and don't do this. In my opinion, it's something that should be opt-in instead of opt-out in all the tools. For example, you can be hit by this while working on a project that doesn't have linting and you update a dependency.

I've done many talks on this before but it's still very opaque to end-users just how much power they give their package manager. Should also be noted that many security tools fail to index/scan git or remote deps ahead of time.

You're right that the solution is to not install these by default unless expressly configured/opted-in to. I have previously considered what it would look like to create an override definition on behalf of the user for git deps (making the consumer aware of/own that resolution long term).

It would also be hard for security tools to scan because the git/https deps can change.