Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

82% of Open-Source Projects Suffer from Tool Rot

blog.trunk.io

Post reply on HN
Print view View original

51–60 of 61 posts

Re: 82% of Open-Source Projects Suffer from Tool Rot

#51

Post by hakre »

dwheeler wrote: post #35
krona wrote: post #20

> It’s important to call out that up until v4 ESLint was vulnerable to a Regular Expression Denial of Service attack (ReDoS). 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.

I think part of the problem is that people aren't distinguishing trusted inputs from untrusted inputs. ReDoS is only a possible problem if untrusted inputs can cause it. Some inputs are trusted, and while it's not crazy to check them (people make mistakes), that's a different kind of concern. ReDoS is a potential security vulnerability, but only in certain special cases. If arbitrary people can insert arbitrary code…

Well written, honestly I find this hard, e.g. not using eslint that often, I have made no clear decision yet in which kind code input from npm for example falls.

Re: 82% of Open-Source Projects Suffer from Tool Rot

#52

Post by 0cf8612b2e1e »

dpkirchner wrote: post #44
0cf8612b2e1e wrote: post #28

Earlier quoted context omitted.

I would settle for knowing I could still build it. It is amazing how fragile build chains are and the amount of maintenance they require. The build tools themselves, let alone pulling in dependencies.

This is the main reason I'm so happy when I see builds run in docker containers. I don't have to worry as much about tracking down the exact dependencies that we're used to build a specific release.

I think docker is a false sense of security. Depending on the language, there can be many implicit system dependencies which you do not pin. If you try to run a container that references ubuntu:13.04, will it still work today? Maybe. Still leagues better than where we were.

I am still hoping for Nix or a version 2 of the project to sweep the world and fix this mess.

Re: 82% of Open-Source Projects Suffer from Tool Rot

#53

Post by Macha »

hakre wrote: post #51
dwheeler wrote: post #35

Earlier quoted context omitted.

I think part of the problem is that people aren't distinguishing trusted inputs from untrusted inputs. ReDoS is only a possible problem if untrusted inputs can cause it. Some inputs are trusted, and while it's not crazy to check them (people make mistakes), that's a different kind of concern. ReDoS is a potential security vulnerability, but only in certain special cases. If arbitrary people can insert arbitrary code…

Well written, honestly I find this hard, e.g. not using eslint that often, I have made no clear decision yet in which kind code input from npm for example falls.

eslint doesn't scan your mode modules. If it did, it would be untrusted, as they could include as .eslintrc.js file and run arbitrary code. However, they could also include a npm post install script and run arbitrary code, or run arbitrary code when your code imports them, so it's not like eslint changes your risk profile in regards to npm dependencies.

Re: 82% of Open-Source Projects Suffer from Tool Rot

#54

Post by dapirian »

dwheeler wrote: post #41

This seems to equate linters with other kinds of tools, and I think that's mistaken. 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…

I think this definition is outdated - linters find real bugs now. The boundaries between linters, static analyzers, and security tools in real life are basically nonexistent, it's entirely tool by tool. Also, autoformatters should style code, not linters. Used to be that linters told you about code style issues, and many still do, but ppl should turn all rules off and use autoformatters instead. Much easier/better.

Re: 82% of Open-Source Projects Suffer from Tool Rot

#55

Post by seba_dos1 »

_aavaa_ wrote: post #13

I didn't see anything about them filtering out repos which have been abandoned, were only for testing, or other such considerations. The title is technically correct, but I feel that most people would interpret it as "82% of active Open-Source projects".

> The title is technically correct

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.

Re: 82% of Open-Source Projects Suffer from Tool Rot

#56

Post by _aavaa_ »

seba_dos1 wrote: post #55
_aavaa_ wrote: post #13

I didn't see anything about them filtering out repos which have been abandoned, were only for testing, or other such considerations. The title is technically correct, but I feel that most people would interpret it as "82% of active Open-Source projects".

> The title is technically correct 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.

Fair enough. What I meant was "even if the tittle is technically correct".

Re: 82% of Open-Source Projects Suffer from Tool Rot

#57

Post by _aavaa_ »

elischleifer wrote: post #18
_aavaa_ wrote: post #13

I didn't see anything about them filtering out repos which have been abandoned, were only for testing, or other such considerations. The title is technically correct, but I feel that most people would interpret it as "82% of active Open-Source projects".

great point. I didn't see a mechanism for filtering out stale projects - if that is a GH concept inside CodeSearch. TLDR; there are a lot of active projects running rusty / rotten tools

I don't see how you can claim that TLDR without a measure of how many of the results are active projects.

Similarly, it's a strong claim to equate "non-latest release" with "rusty/rotten tooling".

Re: 82% of Open-Source Projects Suffer from Tool Rot

#58

Post by mandevil »

woodruffw wrote: post #9

Sometimes I wonder if we're optimizing for the wrong things in the dependency management space: we used to have a distinction between "bleeding edge" and "stable" distribution schemes, with programmers (and users) picking the appropriate channel based on their stability and feature requires. That seems to have been mostly discarded: we now assume that a development dependency is broken and needs to be updated if it's…

The ultimate reason is that security bug fixes are an absolute requirement, and unless someone is paying, most OSS providers aren't interested in doing multiple sets of bug fixes. That is the promise- and entire business model, honestly, of Red Hat, they will backport security bugfixes to your stable version.

Otherwise, since we rely so much on free software development, it kinda has to be that way.

Re: 82% of Open-Source Projects Suffer from Tool Rot

#59

Post by dwheeler »

dapirian wrote: post #54
dwheeler wrote: post #41

This seems to equate linters with other kinds of tools, and I think that's mistaken. 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…

I think this definition is outdated - linters find real bugs now. The boundaries between linters, static analyzers, and security tools in real life are basically nonexistent, it's entirely tool by tool. Also, autoformatters should style code, not linters. Used to be that linters told you about code style issues, and many still do, but ppl should turn all rules off and use autoformatters instead. Much easier/better.

I disagree that the definition is "outdated". Yes, linters find real bugs, I never said they couldn't. But tools typically called "linters" routinely also report things that aren't serious defects, while other tools that focus on specific issues (e.g., security vulnerabilities) tend to find those issues. A "static analyzer" is anything that analyzes code without running it, so linters and Static Application Security Testing (SAST) tools are both kinds of static analysis tools. Linters and SAST tools (for example) tend to focus on different kinds of rules. Under the hood they may use the same underlying technology, but they're applying them differently, so it makes sense to have different words for them.

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.

Re: 82% of Open-Source Projects Suffer from Tool Rot

#60

Post by sdfhbdf »

Alternative title: 82% of projects on GitHub have an outdated code formatting library as a dependency.

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?

Post reply on HN