If only a reason were given. This is the original:
> Rust is a security nightmare. We'd need to add over 130 packages to main for sequoia, and then we'd need to rebuild them all each time one of them needs a security update.
What has changed? Why is 130 packages for a crypto application acceptable?
Debian's tooling for packaging Cargo probably got better, so this isn't as daunting as it used to be.
Another likely thing is understanding that the unit of "package" is different in Rust/Cargo than traditionally in C and Debian, so 130 crates aren't as much code as 130 Debian packages would have been.
The same amount of code, from the same number of authors, will end up split into more smaller packages (crates) in Rust. Where a C project would split itself into components internally in a way that's invisible outside (multiple `.h` files, in subdirectories or sub-makefiles), Rust/Cargo projects split themselves into crates (in a Cargo workspace and/or a monorepo), which happen to be visible externally as equal to a package. These typically aren't full-size dependencies, just a separate compilation unit. It's like cutting a pizza into 4 or 16 slices. You get more slices, but that doesn't make the pizza bigger.
From security perspective, I've found that splitting large projects into smaller packages actually helps review the code. Each sub-package is more focused on one goal, with a smaller public API, so it's easier to see if it's doing what it claims to than if it was a part of a monolith with a larger internal API and more state.
That's not a Rust problem, that's a sequoia problem.
As for why, probably the same reason the dependency tree for gnupg (generate with `debtree -R -b gnupg` but grepping out all the gcc/mingw dependencies) looks like this: https://static.jeroenhd.nl/hn/gnupg.svg There's probably a good reason why I need libjpeg62, libusb-1.0-0-dev, and libgmp3 to compile gnupg, though they're hidden away from the usual developer docs in the form of transitive dependencies; complex software just tends to include external dependencies rather than reinventing the wheel.
Is it? Rust, or rather its online acolytes, deems a simple linked list "too complicated" for mere mortals, and routinely tells people "just" to use a crate that does it for you.
To me, this sounds like "leftpad" but for CS1 data structures.
It depends if the original opinion was a reasoned one or just based on personal feelings.
The dependency explosion is still a problem and I’m not aware of any real solution. It would have been interesting to to see why their opinion changed… I’m guessing it’s as simple as the perceived benefits overriding any concerns and no major supply-chain attacks being known so far.
It depends on how you define supply chain attacks.
Recently, there was an exploit discovered in an abandoned Rust package that was used by many other Rust projects, many unaware of it due to the sheer number of dependencies. Whether by negligence or malice, having a known vulnerability that permeates significant portions of the ecosystem is on the order of a supply chain attack.
Given projects that make the claim of switching to Rust to access new contributors, it remains to be seen how many of those new contributors are capable of being retained.
I would much rather work with someone that other people find abrasive but who communicates much like myself and is clearly open-minded, than the opposite.
