20
estimated audit backlog: 67560 lines
(fedia.io)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 17 Dec 2025
20 points (95.5% liked)
Rust
7586 readers
93 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 2 years ago
MODERATORS
Debian (and other "community" distros) is distributed collaboration, not an organization in the sense you're describing. You're trusting a scattered large number of individuals (some anonymous), infrastructure, and processes. The individuals themselves change all the time. The founder of the whole project is not even still with us for example.
Not only the processes did nothing to stop shipping the already mentioned xz backdoor (malicious upstream). But the well-known blasé attitude towards patching upstream code without good reason within some Debian developer circles actually directly caused Debian-only security holes in the past (If you're young, check this XKCD and the explanation below it). And it just happens that it's the same blasé attitude that ended up causing the xz backdoor to affect PID 1 (systemd) in the first place. While that particular malicious attack wasn't effective/applicable in distros that don't have such an attitude in their "culture" (e.g. Arch).
On the other hand, other Debian developer(s) were the first to put a lot of effort into making reproducible builds a thing. That was a good invaluable contribution.
So there is good, and there is very much some bad. But overall, Debian is nothing special in the world of "traditional" binary distros. But in any case, it's the stipulation "trusting an organization because it has a long track record of being trustworthy" in the context of Debian that would be weird.
(The "stable distro" model of shipping old patched upstreams itself is problematic, but this comment is too long already.)
crates.iois 10+ years old upstream-submitted repository of language-specific source packages. It's both not that comparable to a binary distro, and happens to come with no track record of own goals. It can't come with own goals like the "OpenSSL fiasco" in any case, because the source packages ARE the upstreams. It is also not operated by any anonymous people, which is the first practical requirement to have some logically-coherent trustworthiness into an individual or a group. Most community distros can't have this as a hard requirement by their own nature, although top developers and infrastructure people tend to be known. But it takes one (intentionally or accidentally) malicious binary packager...You don't seem to have a coherent picture of a threat model, or actual specific factualities about Debian, or
crates.io, or anything really, in mind. Just regurgitations about "crates.ioBAD" that have been fed mostly by non-techies to non-techies.I think you are completely missing the point. Packages distributed by Debian are less likely to be insecure because Debian policy requires reviewing all source code to make sure it meets interoperability and open-source standards.
Regardless of how frequently this is actually done, if it's done at all is a point in favor of using Debian distribution. The fact that Debian has introduced errors themselves in a few cases is irrelevant, any developer can do that and crates.io is full of them with not even an attempt at additional review.
You need to balance whether or not the distributor is fixing or introducing more bugs, and in the case of Debian it seems to be overwhelmingly the former.
Your argument that crates.io is a known organization therefore we should trust the packages distributed is undermined by your acknowledgement that crates.io does not produce any code. Instead we are relying on the individual crate developers, who can be as anonymous as they want.
I did not mean to suggest that crates.io is "bad". It's obviously quite useful. It's just that I would like it better if there were some kind of systematic review of newly submitted packages by someone other than their authors, and I would like rust better if its standard library included a random number generator.
I would suggest that Debian is quite good, and is indeed something special, but that's another story.
While it may never be "enough" depending on your requirements (which you didn't specifically and coherently define), the amount of "review", and having the required know-how to do it competently, is much bigger/higher from your crate dependants, than from your distro packages.
It's not rare for a distro packager to not know much about the programming language (let a lone the specific code) of some packages they package. It's very rare for a packager to know much about the specific code of what they package (they may or may not have some level of familiarity with a handful of codebases).
So what you get is someone who pulls source packages (from the interwebs), possibly patching them (and possibly breaking them), compiling them, and giving you the binaries (libs/execs). With source distros, you don't have the compiling and binary package part. With
crates.io, you don't have the middle man at all. Which is why the comparison was never right from the start. That's the pondering I left you to do on your own two comments ago.Almost all sufficiently complex user-space software in your system right now has a lot of dependencies (vendored or packaged), you just don't think of them because they are not in your face, and/or because you are ambivalent to the realities of how distros work, and what distro developers/packagers actually do (described above). You can see for yourself with whatever the Debian equivalent is to pactree (from pcaman).
At least with cargo, you can have all your dependencies in their source form one command away from you (
cargo vendor), so you can trivially inspect as much as you like/require. The only part that adds unknowns/complexities is crates that usebuild.rs. But just likeunsafe{}, this factor is actually useful, because it tells you where you should look first with the biggest magnifying glass. And just like cargo itself, the streamlining of the process means there aren't thousands of ways/places in the build process to do something.One of the things I immediately liked about cargo is that (so far as I've seen thus far) the source is already there, without vendoring, in
~/.cargo/registry. In Debian, to get the source it'sapt-get source $packageand as an end user it's super easy to build things from those source packages if you want to.