estimated audit backlog: 67560 lines
I started learning rust. Worried about trusting all the various code that gets pulled in from the interwebs to compile the first example project in the book (which depends only on “rand” to get random numbers, which requires 8 different libraries), I installed “cargo vet” so that I’d at least know about it if I accidentally added things that haven’t been vetted by anyone at all.
Doing this installed a further 200 crates, with no indication as to whether they have themselves been vetted by anyone or not, and tells me that half the ones I already had just from adding “rand” have not been vetted by anyone.
Anyway, I’m learning rust.
This is the way with modern software engineering, especially in the industry. It comes from the basic fact that:
- Companies want to get code for free from the internet - someone else already wrote that code, let’s use it for free and have better profit margins!
- Companies do not want to spend time and effort vetting that free code, as that would make it… well, not free. That would require manpower (perhaps unless you trust AI to do it these days…) and that’s money.
Basically they want to eat their cake and have it too. This applies to all modern package managers for modern languages that make it easy to distribute your own code and consume free online code.
I doubt the industry will ever mature to a point where this will stop, as the tradeoff of getting free code with no work is just too good for most companies, especially the smaller ones.
It’s definitely a growing problem with Rust. I have noticed my dependency trees growing from 20-50 a few years ago to usually 200-500 now.
It’s not quite as bad as NPM yet, where it can easily get into the low thousands. Also the Rust projects I have tend to have justifiably large dependencies, e.g. wasmtime or Slint. I don’t think it’s unreasonable to expect a whole GUI toolkit to have quite a few dependencies. I have yet to find any dependencies that I thought were ridiculous like leftpad.
We could definitely do with better tooling to handle supply chain attacks. Maybe even a way of (voluntarily) tying crate authors to verified real identities.
But I also wouldn’t worry about it too much. If you a really worried, develop in a docker container, use a dependency cooldown, and whatever you do don’t use cryptocurrencies on your dev machine.
Yeah, the personal risk doesn’t worry me as much as the idea that it might eventually get to be as bad as npm.
fastrandhas zero dependencies.And all external dependencies are “pulled from the interwebs” nowadays (in source and/or binary form), irrespective of language. This includes core, alloc, and std, which are crates that came with your compiler, which you pulled from the interwebs.
I got the compiler and whatever comes with it from the debian package manager, which has existed for much longer than has crates.io and has had fewer malicious packages get into it.
So, we established that “pulled in from the interwebs” is not a valid differentiator.
which has existed for much longer than has crates.io
True and irrelevant/invalid (see below). Among the arguments that could be made for <some_distro> packages vs.
crates.io, age is not one of them. And that’s before we get to the validity of such arguments.In this case, it is also an apples-to-oranges comparison, since Debian is a binary distro, and
crates.iois a source package repository. Which one is “better”, if we were to consider this aspect alone, is left for you to ponder.and has had fewer malicious packages get into it.
The xz backdoor was discovered on a Debian Sid system, my friend. Can you point to such “malicious packages” that actually had valid users/dependants on crates.io?
Trusting an organization because it has a long track record of being trustworthy is “invalid”? You guys are pretty weird.
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 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.
which has existed for much longer than has crates.io
The Rust compiler has not existed for as long as the debian package manager has. You’re still trusting it and its standard library even if your reason for trusting it is that Debian’s maintainers trust it. This is also true of any vetted dependencies you download. You’re trusting others at the end of the day, whether they are the package developers or the auditors. Only by auditing your dependencies yourself can you avoid trusting anyone else.
With that being said, you are also able to contribute here. Someone has to do the auditing. Go audit some packages!
How long did it take you to audit the source code for your OS?
That’s different to developing software. As a developer you are in large part responsible for ensuring that your software doesn’t compromise your users’ security. It’s reasonable to not want to distribute software that may contain malware or just shitty code that is full of vulnerabilities or bugs.
This user wanted to audit the dependencies of
cargo vetwhich is not shipped to an end user. It is part your toolchain in the same way your OS is. One might assume the Linux or BSD kernel has been audited; it is not reasonable to assume the UI stack has because it’s open source. It is equally unreasonable to assume the Windows anything has been audited. It is only slightly reasonable to assume parts of macOS have been audited.You’re only partially correct. If you are not securing the environment in which you code, your code is vulnerable to supply chain attacks. The chances are incredibly low, of course, but nonzero. You also can’t get away with, say, running your editor in a read-only image that only mounts your code because that read-only image could be exfiltrating your data.
Edit: here’s a great example from this year; while the exploit came from a package the attack vector was social engineering. Job postings and related files are a common entry point outside of dev tools.
They may not have been formally vetted, but they are in the sense that the majority of those 200 crates are used widely in everyone else’s projects.
But yeah, this is definitely a blind spot, not just for rust, but all modern build systems that accept code from various sources. At least cargo vet is a step in the right direction.
