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.

Tools making this harder will also encourage npm packages to keep their dependencies on npm because it will cause friction for their users.

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.

Most package managers already categorize the dependency by it's parsed spec (ex. npm's `npm-package-arg` or our internal `@vltpkg/spec`); we just need to create policies to gate installations based on that information. www.npmjs.com/package/npm-... www.npmjs.com/package/@vlt...

For @vlt.sh our policies will use DSS (docs.vlt.sh/cli/selectors). Most cmds already support a `--target` &/or `--scope` flag which use it too. `install` is the laggard since applying complex graph mods during resolution is hard™️ (note: we might just do it post resolution like we did for `build`).

DSS selectors essentially unlock the underlaying data associated with the dependency (ex. it's spec/type/metadata) as well as it's relationships in the graph making it trivial to express complexed/nuanced queries easily.