It really does matter. I don't know enough about this specific case, but multiple order of magnitude differences in CVE numbers are frequently explained by different policies towards finding and assigning CVEs in many many cases.
Absent more information the default should be to hand wave it away as probably such a difference. CVE counts are not a even slightly reliable metric.
Most of them are TOCTOU races or improperly following symbolic links. For example, uutils mkfifo(1) would create a world-readable and writable FIFO before using chmod(2) to restrict its permissions. Another user could replace that file with a symbolic link between the mkfifo(3) call and the chmod(2) to change the permissions of arbitrary files [1].
Other ones I find concerning are that you could also bypass '-- no-preserve-root' with a symbolic link to root [2]. Or by using paths equivalent to "/", e.g., "/../" [3]. Historically, GNU coreutils has been pretty good with symbolic links and avoiding TOCTOU races. The only notable one I can remember is a chmod(1) bug [4].
I agree with your general point that the number of CVEs is a useless metric, though.
The point is that such bugs shouldn't exist in the first place.
Using recursion on unbounded inputs on a programming language that doesn't support that (which are most) is an extremely classical mistake that really should be known to all programmers, especially those of low level languages that care about safety.
Every time you call something recursively you should be thinking "how deep is this?".
By that logic, why even spend effort migrating from a known-working implementation to one which is known to have outstanding bugs that there isn't enough bandwidth to fix?
Like Python 2 vs 3? That's what Editions were created to fix. With backwards incompatibility you will get ecosystem breakage and looming threat of future compilers not compiling your code.
The problem is that assuring no breaks ever with inference means you can't ever improve the inference algorithm nor update the stdlib. This is what triggered the time 0.35 breakage. I have a still incomplete/unmerged rustc lint to avoid the situation that caused that (a useless .into() that didn't get flagged because the clippy lint has false positives so it is not on by default) which should minimize the likelihood of that happening again (once I get off my ass and finish it, it just requires some side-quests to add more accurate tracking of cfg'd out items). This might be able to be mitigated by editions, but in practice crater helps to not need that (yet?).
This is not the only kind of breakage a project can experience. Trying to bring up an older project on a new platform will be a compile error (like building a project from 2018 on an Mx Mac), and updating the appropriate dependency to an appropriate version might become a chore. I have no idea how to improve the situation there to make that less painful, beyond having a simple database of crate-version+platform+rustc-version so that the toolchain could provide better/actionable messaging beyond "shit's broken".
They're good analogies. It's possible to keep a Jenga tower going forever, just extremely difficult once it reaches the point of being all middle pieces.
It's certainly not possible to keep a Jenga Tower growing forever. For each floor you add you need to leave at least one piece in a lower floor. Eventually you run out of pieces. It's possible to "complete" a Jenga Tower, but at that point it has to stop growing.
I somewhat agree... Yaml 1.2 spec is underutilized, and there are too many 1.1 compatible parsers in the wild.
However! The Spec defined alias and anchor, the spec defined loading, emitting, when it should have just called it serialization and deserialization.
There are also other points of problem. Why do we have three block kind of string (unquoted, folded and literal)? Why is there three kind of flow strings(unquoted, single and double quoted)? Why is everything so context (flow/block) sensitive?
The problem with YAML spec is that it tries to serve two masters: be a JSON compatible spec, be compatible with Python like whitespace sensitive config.
I realize that this is a tangent but one of the more sad developments of recent developments as an advocate for open knowledge is how much of it is trapped on servers like discord that will never be indexed by any search engine.
There isn’t even an ability to turn on a feature to have discord chats indexed or anything. I realize it’s not only discord but it’s illustrative of what I perceive as an issue
Was there an audit against coreutils? If not, it's not really apple-to-apple comparison.
reply