“Vetting the cargo”
https://lwn.net/SubscriberLink/897435/397298883e41ef8d/
“There are many ways to improve confidence in the security of a chunk of code. Writing that code in a memory-safe language is one such way […] But more than that is required and, in the end, there is no substitute for simply looking at the code and understanding what it does. […]
The cargo vet mechanism, built into Rust's Cargo dependency manager and build system, is meant to help with the task.”
🧵
The tool seems to be biased towards the use case of Mozilla: most developers and orgs can’t “audit” everything they use.
In practice, it seems that “normal” Rust developers are left out in the cold, hoping that crates they pulled are okay.
3/
The article mentions discussions about building a reputation system that would somehow allow “audit tracking” to be shared among users—e.g., if I trust Mozilla, I can use whichever crate they claim to have audited.
This seems hand-wavy: reputation systems have been a research topic in the context of p2p systems in the 2000s; it’s “complicated”. What was at stake was mostly bandwidth sharing and availability—much less critical than #SupplyChainSecurity.
4/
Other things I find surprisingly vague in the spec:
1. audited packages are designated by name/version strings, which is ambiguous¹ and could lead to confusion about what was actually audited;
2. the meaning of “audit” could vary from one person or org to another.
¹ https://en.wikipedia.org/wiki/Zooko%27s_triangle
5/
I think this model has to be compared to that of traditional GNU/Linux distros.
Distros wouldn’t formally audit all the packages they provide, but they would at least review what gets in, sometimes quite thoroughly (think about copyright tracking in Debian, antifeature and non-free software removal, unbundling, and more.)
They built a social structure around shared values, ensuring that some basic requirements are met.
Is there something “modern” package repos could learn from those?
6/
@civodul aren't there some heuristics that may be applied automatically? packages shouldn't be doing obviously malicious stuff like reading /etc/passwd or fiddling with other processes. unless of course the package is designed for those purposes... then there are some security features that were NOT applied as in the 'please' package that was independently audited. surely some of this audit work can be automated, putting attackers on the other foot to beat the automation.
@theruran It depends on one kind of “audit” one has in mind (security? reliability? fault tolerance?). Tools can help find parts of the code to focus on, but usually, the actually audit cannot be automated.
> Is there something “modern” package repos could learn from those?
I don't think they will ever learn.
language-repos are the industrial tool of shipping things fast and cheap, with basically having the minimum of quality required.
Basic thing: How many of those have a clean/uninstall feature?
Distros are basically the opposite of that, they're unions of users as volunteers, taking the time to do things right is part of it, shipping isn't much of a concern (Debian is ready when it is).
And more importantly: They're a way to get back control from upstream.
my take on this is that it's a knee-jerk reaction to the increasing awareness of their supply chain weaknesses, while holding on to cargo as a draw for developers
@bjc Mozilla depends on Rust for Firefox. As the article mentions, they needed a way to keep things under control; they probably realized that carelessly pulling hundreds of crates in Firefox could lead them to ship malicious code.
In essence, ‘cargo vet’ helps users keep track locally of dependencies they have “audited” so they know where they stand.
It strikes me as inconsistent that on one hand, you’d have a repo (crates.io) where anyone can upload anything without review, and on the other hand, you’d write a tool to not only work around that defect but also keep track of you have “audited”.
2/