Linting: Create a tool that bans dep version ranges

[paulmillr]

Range versions are problematic in context of financial applications. Suppose some package is specified in dependencies as ^1.0.0. This means that on npm install, when 1.0.1 is released, it would be auto-installed. If an adversary gains access to the package, and publishes malware in 1.0.2, ejs users would automatically get malware.

I've pinned versions manually in the past, but over the time new contributors would, by lack of knowledge, would add ranges back.

NPM can't be assumed to remove malware: for example, i've reported the account around 3 weeks ago and nothing is done.

There are 3 parts:

• Low-priority: ensure devDependencies are not using ranges
• High-priority: ensure dependencies are not using ranges
• Also important: ensure dependencies do not duplicate dependencies (1.0.0 and 1.1.0)

The tool which checks this (inside of all package.json) could be simple and consume as few as 1-2 hours of work. It doesn't need any dependencies itself. The tool should auto-run inside of CI on every commit.

[holgerd77]

We had this discussion a while ago already and I am still not fully convinced.

Software tends to improve over time, and there are on the counter-side also the cases, where security holes and vulnerabilities are fixed. It is just not realistic that we oberserve all our dependencies + the dependencies of dependencies all the time and do re-releases of our libraries on each case where a vulnerability is fixed. And also - on the other side - completely out of our control is the need for consuming users to update our libraries as well. From past experiences this seems unrealistic.

So my thesis is that software stacks with range versions "stay in healthy periods (dependency constallations)" for a longer time than software stacks with pinned down versions.

I know this is just "my guts" and I am happy to be proven wrong (e.g. by very clear and traceable statistics)! 🙂 Until then I would stick to the practice we have within the EthereumJS stack.

[paulmillr]

Software tends to improve over time

Not always true. For example, clang got 2x slower in 10 years, massively more complex, while only (sometimes) gaining 15% of perf. Because of its complexity, all sorts of new hard-to-spot bugs arise, which cause millions of dollars of wasted hours.

That was described by creator of ed25519 in the blog post https://blog.cr.yp.to/20240803-clang.html

From my personal experience, some packages do get better. For example, I check every release of Typescript, and upgrade once per 6 months or so. However, typescript is being developed by serious org with planning etc. I can’t confirm whether something like Mocha got better in 10 years. Maybe it got worse because old code can’t always be ran. Overall, most packages are getting bloated, and mostly useless upgrades.

the cases, where security holes and vulnerabilities are fixed

Dependabot would notify us about these. Most of security “holes” these days are “regular expression DoS” and are barely possible to exploit.

What I will do: briefly listing / analyzing all packages and seeing what we’re using, their upgrades and past vulnerabilities.