> Let me rephrase this, 17% of the most popular Rust packages contain code that virtually nobody knows what it does (I can't imagine about the long tail which receives less attention).<p>I think this post has some good information in it, but this is essentially overstated: I look at crate discrepancies pretty often as part of reviewing dependency updates, and >90% of the time it's a single line difference (like a timestamp, hash, or some other shudder between the state of the tree at tag-time and the state at release-time). These are non-ideal from a consistency perspective, but they aren't cause for this degree of alarm -- we <i>do</i> know what the code does, because the discrepancies are often trivial.
Not only this, but the reason we can check what the discrepancy is is because crates.io distributes source code, not binaries, so they can always be inspected. In the end, whats in crates.io is the source of truth.
Isn't the point that unless actually audited each time, the code could still be effectively anything?
Yes, but that's already the case. My point was that <i>in practice</i> the current discrepancies observed don't represent a complete disconnect between the ground truth (the source repo) and the package index, they tend to be minor. So describing the situation as "nobody knows what 17% of the top crates.io packages do" is an overstatement.
> So describing the situation as "nobody knows what 17% of the top crates.io packages do" is an overstatement.<p>Noting that you willfully cut the qualifying "virtually" from that quote, thereby transforming it to over-stated:<p>> Let me rephrase this, 17% of the most popular Rust packages contain code that virtually nobody knows what it does
I think it just depends on whether or not you interpret the phrase "no one knows" neutrally or pessimistically.<p>Saying that there could be something there, but "no one knows" doesn't mean that there <i>is</i> something there. But it's still true.
If that's the case, it would be a lot simpler (and equally accurate) to say that "no one knows" what the source repo is doing, either! The median consumer of packages in <i>any packaging ecosystem</i> is absolutely not reading the entire source code of their dependencies, in either the ground truth or index form.
Serious consideration: Claude Mythos is going to change the risk envelope of this problem.<p>We're still thinking in the old mindset, whereas new tools are going to change how all of this is done.<p>In some years dependencies will undergo various types of automated vetting - bugs (various categories), memory, performance, correctness, etc. We need to think about how to scale this problem instead. We're not ready for it.
> we do know what the code does<p>You know if you check. Hardly anyone checks. It's just normalization of deviance and will eventually end up with someone exploiting it.
Talked about this topic here on my blog<p><a href="https://vincents.dev/blog/rust-dependencies-scare-me/" rel="nofollow">https://vincents.dev/blog/rust-dependencies-scare-me/</a><p>It sparked some interesting discussion by lots of the rust maintainers<p><a href="https://news.ycombinator.com/item?id=43935067">https://news.ycombinator.com/item?id=43935067</a><p>A fat std lib will definitely not solve the problem. I am a proponent of the rust foundation taking packages under their wing and having them audited and funded while keeping original maintainers in tact
> In a recent analysis, Adam Harvey found that among the 999 most popular crates on crates.io, around 17% contained code that do not match their code repository.<p>Huh, how is this possible? Is the code not pulled from the repository? Why not?
> Let me rephrase this, 17% of the most popular Rust packages contain code that virtually nobody knows what it does (I can't imagine about the long tail which receives less attention).<p>I dug into the linked article, and I would really say this means something closer to 17% of the most popular Rust package versions are either unbuildable or have some weird quirks that make building them not work the way you expect, and not in a remotely reproducible fashion.<p><a href="https://lawngno.me/blog/2024/06/10/divine-provenance.html" rel="nofollow">https://lawngno.me/blog/2024/06/10/divine-provenance.html</a><p>Pulling things into the standard lib is fine if you think everyone should stop using packages entirely, but that doesn't seem like it really does anything to solve the actual problem. There are a number of things it seems like we might be forced to adopt across the board very soon, and for Rust it seems tractable, but I shudder to think about doing it for messier languages like Ruby, Python, Perl, etc.<p>* Reproducible builds seems like the first thing.<p>* This means you can't pull in git submodules or anything from the Internet during your build.<p>* Specifically for the issues in this post, we're going to need proactive security scanners. One thing I could imagine is if a company funnels all their packages through a proxy, you could have a service that goes and attempts to rebuild the package from source, and flags differences. This requires the builds to be remotely reproducible.<p>* Maybe the latest LLMs like Claude Mythos are smart enough that you don't need reproducible builds, and you can ask some LLM agent workflow to review the discrepancies between the repo and the actual package version.
> and I would really say this means something closer to 17% of the most popular Rust package versions are either unbuildable or have some weird quirks that make building them not work the way you expect<p>No, what it means is that the source in crates.io doesn't match 1:1 with any commit sha in their project's repo. This is usually because some gitignored file ended up as part of the distributed package, or poor release practice.<p>This doesn't mean that the project can't build, or that it is being exploited (but it is a signal to look closer).
I'm not really convinced that having a few more libraries in the standard library or decentralizing the library repository is going to change much the risks
This is where the whole TPM / trusted computing / secure enclave <i>could</i> be useful to secure developer keys; an unencrypted .ssh/id_rsa file is just too much of a tempting target (also get off RSA already!)
Rust should add a way to sandbox every dependency.<p>It's basically what we're already doing in our OSes (mobile at least), but now it should happen on the level of submodules.
I really like the idea of implementing the std lib separate from the language. I think that would be a huge blessing for Java, Go and others, ideally allowing faster iteration on most things given that we usually don't need a reinvention of the compiler/runtime just to make a better library.
As long as you can include only the parts that you need.<p>In Java, the "stdlib" that comes with the JRE, like all the java.* classes, counts 0 towards the size of your particular program but everyone has to have the whole JRE installed to run anything. Whereas if you pull in a (maven) dependency, you get the entirety of the dependency tree in your project (or "uberjar" if you package it that way).<p>Then we could decide on which of java.util.collections, apache commons-collections, google guava etc. become "standard" ...
<i>> I really like the idea of implementing the std lib separate from the language. I think that would be a huge blessing for [...] Go</i><p>Go's stdlib <i>is</i> separate from the language. The language spec doesn't specify a standard library at all. It also doesn't have just one stdlib. tinygo's stdlib isn't the same as gc's, for example.<p>I will note that gc's standard library also isn't written in Go. It is written in a superset with a 'private' language on top that is tied to the gc compiler to support low-level functions that Go doesn't have constructs for. So separating the standard library from the compiler wouldn't really work. No other compiler would be able to make sense of it. go1 promise aside, some of the higher-level packages that are pure Go could be hoisted completely out of the stdlib, granted.
Random question, does cargo have a way to identify if a package uses unsafe Rust code?
No, but you can use cargo-geiger[1] or siderophile[2] for that.<p>[1]: <a href="https://github.com/geiger-rs/cargo-geiger" rel="nofollow">https://github.com/geiger-rs/cargo-geiger</a><p>[2]: <a href="https://github.com/trailofbits/siderophile" rel="nofollow">https://github.com/trailofbits/siderophile</a>
Also to note that RS domain is Serbia, who could simply redirect all rust users to malicious domains in a supply chain attack.
But it's impossible to have a buffet overflow in rust
Why not pin your packages? Andnwhy not have M of N auditors sign off on releases?
Eh, the only way to secure your Rust programs it the technique not described in the article.<p>Vendor your dependencies. Download the source and serve it via your own repository (ex. [1]). For dependencies that you feel should be part of the "Standard Library" (i.e. crates developed by the Rust team but not included into std) don't bother to audit them. For the other sources, read the code and decide if it's safe.<p>I'm honestly starting to regret not starting a company like 7 years ago where all I do is read OSS code and host libraries I've audited (for a fee to the end-user of course). This was more relevant for USG type work where using code sourced from an American is materially different than code sourced from non-American.<p>[1]: <a href="https://docs.gitea.com/usage/packages/cargo" rel="nofollow">https://docs.gitea.com/usage/packages/cargo</a>
The only thing this leads to is that you'll have hundreds of vendored dependencies, with a combined size impossible to audit yourself.<p>But if you somehow do manage that, then you'll soon have hundreds of <i>outdated</i> vendored dependencies, full of unpatched security issues.
> full of unpatched security issues<p>If you host your own internal crates.io mirror, I see two ways to stay on top of security issues that have been fixed upstream. Both involving the use of<p><pre><code> cargo audit
</code></pre>
which uses the RustSec advisory DB <a href="https://rustsec.org/" rel="nofollow">https://rustsec.org/</a><p>Alternative A) would be to redirect the DNS for crates.io in your company internal DNS server to point at your own mirror, and to have your company servers and laptops/workstations all use your company internal DNS server only. And have the servers and laptops/workstations trust a company controlled CA certificate that issues TLS certificates for “crates.io”. Then cargo and cargo audit would work transparently assuming they use the host CA trust store when validating the TLS certificates when they connect to crates.io. The RustSec DB you use directly from upstream, not even mirroring it and hosting an internal copy. Drawback is if you accidentally leave some servers or laptops/workstations using external DNS, and connections are made to the real crates.io instead. Because then developers end up pulling in versions of deps that have not been audited by the company itself and added to the internal mirror.<p>Alternative B) that I see is to set up the crates host to use a DNS name under your own control. E.g. crates dot your company internal network DNS name. And then set up cargo audit to use an internally hosted copy of the advisory DB that is always automatically kept up to date but has replaced the cargo registry they are referring to to be your own cargo crates mirror registry. I think that should work. It is already very easy to set up your own crates mirror registry, cargo has excellent support built right into it for using crates registries other than or in addition to crates.io. And then you have a company policy that crates.io is never to be used and you enforce it with automatic scanning of all company repos that checks that no entries in Cargo.toml and Cargo.lock files use crates.io.<p>It would probably be a good idea even to have separate internal crate registries for crates that are from crates.io and crates that are internal to the company itself. To avoid any name collisions and the likes.<p>Regardless if going with A) or B), you’d then be able to run cargo audit and see security advisories for all your dependencies, while the dependencies themselves are downloaded from your internal mirror of crates.io crates, and where you audit every package source code before adding it in your internal mirror registry.
A large number of security issues in the supply chain are found in the weeks or months after library version bumps. Simply waiting six months to update dependency versions can skip these. It allows time to pass and for the dependency changes to receive more eyeballs.<p>Vendoring buys and additional layer of security.<p>When everyone has Claude Mythos, we can self-audit our supply chain in an automated fashion.
Coding agents should help us reduce dependencies overall. I agree Go is already best positioned as a language for this. Using random dependencies for some small feature seems archaic now.