If one points out ReDos 'vulnerabilities' in tooling as a reason to upgrade it, you've instantly lost the argument.
By the same logic we should ban TypeScript because its type system is turing complete. This reasoning isn't even wrong.
The proliferation of ReDoS "vulnerabilities" has been extremely frustrating (as someone working on accurate and high-signal vulnerability reporting tools), and belies completely perverse incentives in the bug bounty/vulnerability reporting space (reporters are incentivized to obtain CVEs to pressure companies into accepting low-quality reports).
If arbitrary people can insert arbitrary code into what your service sends, and other people will then run it, then ReDoS isn't even the beginning of your security problems.
We are codes transport mechanism, without us, its not alive. And only good code gets copied, reused, to life on till heat death.
Documentation is a constant fight against entropy.
Working safely is a constant fight against entropy/complacency.
And so on
Is it? Where did the 82% figure even come from? Are 82% of all Open Source projects even written in languages with tooling that promotes projects to self-manage their dependencies?
The world doesn't end at JavaScript, Python, or even Rust.
TLDR; there are a lot of active projects running rusty / rotten tools
Similarly, it's a strong claim to equate "non-latest release" with "rusty/rotten tooling".
That seems to have been mostly discarded: we now assume that a development dependency is broken and needs to be updated if it's even slightly stale, despite being stable and working just fine. I can understand part of why that is (e.g. the overhead required to support multiple versions), but I think it's shortsighted of us to treat non-adherence to the "bleeding edge" as a security or code smell.
Still, I wonder about the general propriety: not every bug fix is a security fix, and treating them as such produces noise and fatigue that reduces the overall effectiveness of vulnerability reporting (since engineers become desensitized to reports).
Much of Rust's ecosystem embodies this: there are crates (like serde and clap) that have extremely regular bugfix releases, but those fixes do not (to my knowledge) surface as security concerns; instead, they're usually small invariant checks or missing trait implementations.
Otherwise, since we rely so much on free software development, it kinda has to be that way.
- A real security issue - things like the reDoS example cited are part of the crying wolf that causes people to treat security scanners less seriously
- A new feature (lint rule in eslint's case, or maybe new JS syntax support) is desired. The new upgrade can be deferred until that time
- You're doing updates _anyway_ and update eslint as part of that housekeeping.
2. What are the security issues that can be found in a local tool which has as its only input your own code and it's output is only printed in tooltips for human review? Even if you had a way for specially formed code to run other code in eslint, it's a bit like saying bash has an RCE because you can type a command into it.
Does this ring true for anyone? This sounds like hell. I am so glad to be in a field that minimizes third party dependencies.
The C code I write today would run the same 20 years ago and will run the same 20 years from now.
When Java came out, we went through the tool hell described in this article.
Still miles better than the JS and cloud spaces where code has such a short half-life you need to handle it with tongs and keep it in a lead box when you aren't using it, but still. All code rots.
- configuration changes in the new versions
- undocumented changes in the new versions
- subtle changes in the build result that lead to flaws in the artefacts
- some of them leading to security flaws (those in the real camp)
- some of them leading to data-loss when running on production systems.
But sure, if you have kept the linter up-to-date ... .
Linters attempt to look for "less than best practices". When you update a linter, you often also need to update code for the new style rules (unless you just don't care about the results). Those reports can be helpful, because those style rules can also warn about real problems like security vulnerabilities. But most are minor issues, so it may make sense to delay them.
I would generally prioritize outputs of tools that are designed to find serious problems (like security vulnerabilities), and then update things like linters when I can (but consider those lower priority). We should be unsurprised to find developers prioritizing some kinds of reports over others.
So let's look at ESLint's list of rules: https://eslint.org/docs/latest/rules/ Here are some examples:
* getter-return: Enforce `return` statements in getters
* no-constant-condition: Disallow constant expressions in conditions
* no-fallthrough: Disallow fallthrough of `case` statements
* no-irregular-whitespace: Disallow irregular whitespace
You might find real bugs with these linting rules, sure. But if I want to prioritize finding and fixing security defects, I'll prioritize fixing the security defects found by a tool designed to find the most likely kinds of security defects (e.g., look for XSS, SQL injection, etc.). Not these rules. You can have code that violates many ESLint rules and still works correctly for end-users.
That doesn't mean linters are useless. Quite the contrary, I think linters are really helpful & I strongly encourage their use. Fixing issues found by linters can not only fix real bugs, but they can sometimes encourage creation of simpler code that is easier to analyze by both humans and machines. But I wouldn't prioritize updating a linter over updating other tools and fixes. Yes, update linters, but when you have limited resources, that's not where you spend your first hour.
I think there's a lot of legitimate debate about autoformatters, that's a different topic.
Oh my god, your vscode/text editor will freeze or crash if your code contain a specially crafted string. What a very import thing to call out.
Kind of glossing over what's often the hardest part. Sure, ESLint (the author's example) might be easy enough, but who hasn't seen a new compiler or key library cause problems? Bugs, including security bugs, can be introduced as well as fixed. Often these problems are hard to notice (until they bite you hard) and/or work around. While the solution to the easiest part is not unwelcome, software supply chain issues are much more complex and difficult than "once you've confirmed" would suggest.
Also: stealth advertising. :-P
1. key system dependencies -- this includes things like Android APIs, IDE APIs, etc. ~ to work on newer versions of those platforms, you need to upgrade and make changes to the code
2. other runtime dependencies -- these are dependencies used to make the system run, but that don't need to be updated in sync with the target platform ~ this can be things like the version of Spring, a HTTP library, etc.
3. development dependencies -- these are dependencies used to build the project
The system dependencies result in a treadmill, where if you don't keep up with the changes then your application, plugin, etc. will no longer work on the latest version. Just keeping up with these can be a lot of work, especially if you need/want to support multiple versions.
The other dependencies can cause headaches when upgrading major (or even minor) versions. For example, making sure that all the libraries you use are compatible when upgrading another library or language (Scala, Python, Java, PHP, etc.). This can be a lot of work to make sure that nothing is broken.
Development dependencies are typically low on the priority of things to upgrade. If the version of ESLint you are using works and there are no key benefits of performing an upgrade, then it is less likely to be upgraded.
I wouldn’t call this tool rot. This to me seems like fear-mongering to drive conversions of yet another tool for managing dependencies from the company behind this blog post.
It would be interesting to maybe analyse usage of React, Django, Laravel or such popular projects which you might be certain are key to a GitHub project and might lead to some interesting observations.
Instead i would summarise this article as a graph of a few searches on github that give you as much data as relevant stats page from npm or PyPI - not much.
What conclusions can we draw that some projects on github, which we have no idea how big or how used they are, run an outdated code formatter? Maybe 82% of them are archived, abandoned or were one offs to learn the language?
It's a constant battle to build projects that shipped 18 months ago. One thing wasn't pinned. Or the build system used node 12 and doesn't run on CI anymore. So Babel needs updated. CDK did a major rev and now we have to force pin the old version.
You don't need always the newest "sht".
