less likely to be insecure

Evidenced by?

requires reviewing all source code

This is exactly the la-la-land view of what distributors do I was dispelling with facts and reality checks. No one is reviewing all source code of anything, except for cases where a distro developer and an upstream member are the same person. And even then, this may not be the case depending on the upstream project, its size, and the distro developer’s role within that project.

to make sure it meets interoperability

Doesn’t mean anything other than “it builds” and “API is not broken” (e.g. withing the same .so version), and “seems to work”.

These considerations happen to hardly exist with the good tooling provided by cargo.

and open-source standards.

Doesn’t mean anything outside of licensing (for code and assets), and “seems to work”.

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.

Largely correct. But that was me comparing middle-man vs. middle-man. That is if crates.io operators can be described as middle-men, since their responsibilities (and consequently, attack vectors) are much smaller.

Barring organizational attacks from within, with crates.io, you have one presumably competent/knowledgable, possibly anonymous, source, and operators that don’t do much. With a binary distro, you have that, AND another “middle-man” source, possibly anonymous, and with competence and applicable knowledge <= upstream (charitable), yet put in a position to decide what to do with what upstream provides, or rather, provided… X years ago, if we are talking about the claimed “stable” release channel.

The middle man pulls sources from places like crates.io anyway. So applying trivial “logic”/“maths”, it can’t be “better”, in the context being discussed.

Software doesn’t get depended on out of thin air. You are either first in line directly depending on a library, and thus you would naturally at least make the minimum effort to make sure it’s minimally “fit for purpose”. Or you are an indirect dependant, and thus looking at your direct dependencies, and maybe “trusting” them with the “trickle down”.

More processes, especially automated ones, are always welcome to help catch “stuff” early. But it is no surprise that the “success stories” concern crates with fat ZERO dependants.

Processes that help dependants share their knowledge about their dependencies (a la cargo vet) are unquestionably good additions. They sure trump the dogmatic blind faith in distros doing something they simply don’t have the knowledge or resources to do, or the slightly less dogmatic faith in some library being “trustable” if packaged by X or XX distros, assuming at least someone knowledgable/competent must have given a thorough look (this has a rough equivalent in the number of dependants anyway).

This is all obvious, and doesn’t take much thought from anyone active from the inside (upstreams or distros), instead of the surface “knowledge” that leaks, and possibly gets manipulated, in route to the outside.