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.

you are viewing a single comment's thread
view the rest of the comments

[–] BB_C@programming.dev 2 points 2 weeks ago (1 children)

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 like unsafe{}, 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.

[–] kbal@fedia.io 2 points 2 weeks ago

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's apt-get source $package and as an end user it's super easy to build things from those source packages if you want to.