Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linting: Create a tool that bans dep version ranges #3773

Open
paulmillr opened this issue Oct 26, 2024 · 2 comments
Open

Linting: Create a tool that bans dep version ranges #3773

paulmillr opened this issue Oct 26, 2024 · 2 comments

Comments

@paulmillr
Copy link
Member

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
Copy link
Member

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
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants
@paulmillr @holgerd77 and others