How are dependencies picked and how to trust those?

[karfau]

Hey there, I wanted to finally try the cli after learning about the manifest confusion issue. I was surprised that the only way to do that that is described in the docs is to use npm, the tool I don't want to trust in the first place...

When checking the report for the package on socket.dev it has a really bad score on the supply chain part and it lists 199 dependencies. I assume this includes common devDependencies, but there are even quite some dependencies for the package.
(As far as I know there is no easy way to distinguish/filter issues between dependency types on socket.dev, but that is an issue of itself)

Also I'm not aware of a nice way to make sure globally installed packages are being kept up to date...

Because of all of this I would suggsst you start thinking about other ways of distributing this cli, which ideally:

• does not require installing packages from npm
• provide an automatic update mechanism
• is transparent on how it is build from source
• is officially supported and maintained by socket.dev

The first ideas that came to my mind but which do not full wishes listed above:

• create a bundled source distribution that contains all the dependencies on a branch with immutable version tags, so people can clone the repo and pull in updates
• create a binary (as in standalone executable) distribution of some kind, but of course this comes with quite some other questions.

Those ideas are of course heavily inspired by the tooling that comes with deno.

[bmeck]

@karfau Heya! Thanks for the interest.

does not require installing packages from npm

npm is a fairly common distribution mechanism and allows ease of use and installation. This is the most likely means of installing things and we welcome enhancements for how to do so but we are not currently looking at alternative distribution systems.

provide an automatic update mechanism

This CLI does perform update checks and instructs on how to update periodically already.

is transparent on how it is build from source

This repository follows a standard node.js/npm based development pattern; introducing a CONTRIBUTING.md might be good though.

is officially supported and maintained by socket.dev

This repository is maintained by socket.dev already.

create a bundled source distribution that contains all the dependencies on a branch with immutable version tags, so people can clone the repo and pull in updates

It is certainly possible to do this with just using bundledDependencies but that workflow is incredibly uncommon to the point it may actually cause problems when installing with some tooling.

create a binary (as in standalone executable) distribution of some kind, but of course this comes with quite some other questions.

We are not currently looking to do this at this time using any of the various runtimes that do provide this including but not limited to node's single executable application system. Providing a single file bundled form seems more likely and portable.

[karfau]

Thx for your detailed reply.

I think something went completely wrong, since I received some answers, but my actual problem as not addressed...

It looks like my original problem was not really understood/agreed upon, so suggesting solutions for the problem was a bit to early.

So let's go step by step:

Assume I heard about the "manifest confusion" and that socket is the only way to protect myself currently.
And I find out they offer a CLI for that. 🎉
I go to the docs on how to install it and it says npm i -g @socketsecurity/cli.

Simple enough, right? But since I want to be extra careful, I check that package on socket.dev:

Wow, that's not a great start.

At first glance it looks like, to install the tool that protects me from manifest confusion I have to install a (transient dependency) package that has the issue.

And with 200(?) dependencies, clicking through all the listed issues and understanding if they are relevant/safe to ignore for my purpose is not really trivial.

Hovering over the bad supply chain score indicates even different numbers for the amount of dependencies.

Checking the critical issue reveals

Which doesn't make to much sense, even when looking at the link to the package.json, I assume that the scripts were dropped before publishing to npm, but I assume it's safe to ignore ...?
(Sad about this being listed as critical in that case.)

The other issues seem to also make sense inthe context of what I understood the cli tool is doing.

Running the suggested install command actually installs 226 packages.
That's quite a bunch.

At first glance it looks like there are quite some that I would consider devDependencies (like @babel/* and @types/*), but they seem to be transitive deps.
And there are some that seem to have some overlap in functionality:

• minimatch and globby
• chalk and prompt > kleur
• ...?

I'm not fully able to figure out where those 226 installed packages come from, but I'm sure you have to right tools to understand that and potentially avoid some of those?
http://npm.anvaka.com/#/view/2d/%2540socketsecurity%252Fcli

Do you have some process for deciding which dependencies to pick for the CLI or SDK?

I think what I would have expected is some kind of hint in the docs or readme regarding those issues, that help me to understand why those things are not an issue I need to worry about.

And with such a huge dependency tree, it seems to be quite cumbersome to do this investigation on each update.
So I wonder if there are nay measurements in place to "eat your own dog food" for this tool, to e.g. make sure that new versions don't contain certain kind of issues reported by socket, so users don't need to review that data.

I think the core topic here is trust has to be earned for a "new tool" that is supposed to protect me from an issue with a tool that "has been around forever".

I'm just trying to understand what your perspectives on these matters are, to build that trust.