/bin/true bloat, and /bin/cat

Posted Mar 19, 2025 16:47 UTC (Wed) by hmh (subscriber, #3838)
In reply to: /bin/true (was Performance concerns when heavily used in scripts ?) by willy
Parent article: Oxidizing Ubuntu: adopting Rust utilities by default

Huh, it goes further. The output of GNU /bin/true --help is fully i18n'd and l10n'd by the distros, for example...

It is still fast when you use it as you're supposed to (i.e. no parameters), small enough on anything that isn't embedded (and would use busybox or toybox instead). And it is not going to create security issues that are not present everywhere else (because it just links to glibc, and it is using glibc's i18n). But yeah, it *is* bloated for no good reason: there's a man page, so /bin/cat really doesn't need or benefit in any way from --help or --version, and the minimal /bin/true and /bin/false would be a lot smaller.

That said, on anything worth of notice, true and false are going to be shell builtins.

Now, GNU /bin/cat is optimized to all heck, that would be a more interesting one to compare with the rust version...

Anyway, this particular rust project explicitly opted into the dependency hell pattern, and thus IMO it is too much of a dependency chain vulnerability for something that I'd run :-(

/bin/true bloat, and /bin/cat

Posted Mar 20, 2025 11:25 UTC (Thu) by chris_se (subscriber, #99706) [Link] (5 responses)

> Anyway, this particular rust project explicitly opted into the dependency hell pattern, and thus IMO it is too much of a dependency chain vulnerability for something that I'd run :-(

Yes, that's my main issue with the current state of affairs w.r.t. Rust. I rather like the language itself, but I'm utterly baffled that many Rust people saw what was going on with npm and thought "sure, let's do more of that". (Ok, it's not quite as bad yet as leftpad, but still...)

/bin/true bloat, and /bin/cat

Posted Mar 21, 2025 8:36 UTC (Fri) by taladar (subscriber, #68407) [Link] (4 responses)

I will never understand the people who complain about number of dependencies without taking into account size of dependencies. Sure, C or C++ have a lower number but that is mostly because each dependency is artificially inflated to a huge size because the build tooling is so bad that nobody wants to split them up into separate libraries.

I'd much rather have a hundred small Rust dependencies than one Qt or openssl that comes with hundreds of critical bugs and security holes that do not even affect the part of it I am using but I have to deal with the related upgrades and CVEs anyway.

/bin/true bloat, and /bin/cat

Posted Mar 21, 2025 11:26 UTC (Fri) by excors (subscriber, #95769) [Link] (1 responses)

One of the significant concerns about number of dependencies is the vulnerability to supply chain attacks, and I think small dependencies actually make that worse, even if the number remains constant.

In C++, if I want something very simple like a circular buffer class, I might find it as part of Boost. That's a huge dependency for such a little feature, which does have some drawbacks. But because it's huge I can be confident there are many developers working on the project. There are review processes, and if one developer tries to slip in something naughty then there's a reasonable chance another developer will spot it before it's released. Security researchers will be running their tools over it. If a vulnerability is reported, there are responsible maintainers who will respond promptly.

If I want the same in Rust, I'll probably find a library that is just one random guy on GitHub. A lot of the code has probably been reviewed by exactly zero other people. There is nothing to mitigate against that developer being malicious, or having their GitHub account compromised, or carelessly accepting a pull request from another random user. They might ignore a vulnerability report for months. They're lacking all the processes and shared responsibility that comes from being in a large project.

I'd agree the huge dependencies will probably have more accidental vulnerabilities, because the sheer quantity of code will outweigh the improved review processes - but Rust's memory safety should already mitigate a lot of that risk, compared to C/C++. That means deliberate backdoors are a relatively greater risk, even before attackers realise there aren't enough buffer overflows and use-after-frees left for them to exploit and they'll have to shift towards more supply chain attacks.

/bin/true bloat, and /bin/cat

Posted Mar 24, 2025 10:13 UTC (Mon) by taladar (subscriber, #68407) [Link]

On the other hand Rust's small dependencies have regular "unmaintained" notifications while the large dependency probably has a good percentage of code that nobody looked at in years. In fact I think I still have a Qt Widget bug open from 10 years ago somewhere that has been migrated through 2-3 different issue trackers by now.

/bin/true bloat, and /bin/cat

Posted Mar 23, 2025 15:53 UTC (Sun) by surajm (subscriber, #135863) [Link] (1 responses)

I think the benefit of the c++ approach is that maintenance for the libraries is generally less concerning. Group ownership of libraries feels a lot safer than tons of tenuously owned and maintained libraries. You don't need to put everything in a single repo or dependency to make this work of course but if you do put everything in one repo then that ownership structure is forced. And to be clear there are many examples of the above approach in the rust ecosystem as well. It's just difficult to ensure all of your deps originate from such entities as there are such deep layers of transitive dependencies, which is again less likely in the c++ ecosystem.

I hope to see this situation improve over time as larger organizations continue to adopt rust and place more strict rules on allowable dependencies.

/bin/true bloat, and /bin/cat

Posted Mar 23, 2025 17:11 UTC (Sun) by farnz (subscriber, #17727) [Link]

I suspect, though, that this is more "vibes" than reality; sure, a big dependency with several maintainers looks healthier from the outside, but in practice, it's not that rare for a big dependency to internally be several small fiefdoms, each of which has just one maintainer. You thus have something that actually hasn't seen maintenance for years, but it "looks" maintained because it's part of a bigger thing where the other bits are well-maintained.