This sounds a lot like cargo-crev but without off-line cryptographic signatures, a significant downgrade in my view.<p>Edit: Yep: <a href="https://mozilla.github.io/cargo-vet/design-choice-faq.html#how-does-this-relate-to-cargo-crev" rel="nofollow">https://mozilla.github.io/cargo-vet/design-choice-faq.html#h...</a><p>None of the reasons given by Mozilla seem to justify the downgrade in security, especially since most can be worked around with crev which already employs secure and well-tested authentication schemes.<p>What also makes this situation peculiar to me is that it's being immediately rushed into Cargo proper instead of the usual way these tools are handled by the Cargo team (i.e. allowing multiple ideas to compete as third-party tools and maybe choosing one once a winner is clear). I understand the recent string of security issues might have played a role here, but I wouldn't expect their reaction to be steamrolling an inferior version of crev as a builtin tool.<p>I would really like to know what happened here.<p>Disclosure: I use neither tool, but I'm very interested in the security and health of the Rust ecosystem.
> Each new participant automatically contributes its audits back to the commons, making it progressively less work for everyone to secure their dependencies.<p>This is really exciting and I hope it gets adopted by all package ecosystems.<p>Of course audits can't guarantee to find the most underhanded "bugdoors", but it will still be a huge step forwards if third parties can vouch for various properties of the code you are about to install, such as it being reproducibly built from a tagged release on a public repository, with no Unicode homoglyphs or unexplained high-entropy strings in the code, and the unit tests all passing.<p>This will naturally lead to the question of who can be trusted to provide these audits, but such automatable checks could be done by almost anyone and their reputation could grow with time (which might lead to second-layer systems which track which auditors make the most accurate claims). Perhaps there will be companies that offer cyber-insurance against these specific threats, and use the premiums from that to fund the audit checks.
Alternatives to cargo-vet that has been mentioned before here on HN:<p>- <a href="https://github.com/crev-dev/crev" rel="nofollow">https://github.com/crev-dev/crev</a><p>- <a href="https://github.com/vouch-dev/vouch" rel="nofollow">https://github.com/vouch-dev/vouch</a><p>Anyone know of any more alternatives or similar tools already available?
I’m hesitant about this effort too, but for different reasons than the ones mentioned already. “Vetting” code for the kernel means something very different than vetting code for a normal application. I mean sure, you want to make sure that the code is functional and free of bad practices that may hide bugs or vulnerabilities, but that’s kind of where the mutual needs end. Kernel code in some cases may not allocate, or may have to avoid the use of certain vector registers. Locking and synchronization in the kernel usually looks pretty different from what you’d want to do in userspace. I’m not entirely against the idea of using third party crates in the kernel but it seems to me that you’d want something better than just “Mozilla ships this in Firefox and they got one of their security engineers to look at it so it’s probably good” that this vetting process seems to provide.
Having heard about this for the first time, I think it's a great initiative. However, I'm concerned about the liabilities of having vetted a crate only to accidentally (ie non-maliciously) miss some kind of vulnerability.<p>Could this lead to the auditor getting sued?<p>I wouldn't mind getting a legal take on cargo-vet and similar tools.
Does anyone have a link to Mozilla's audits.toml?<p>I found one in Mozilla's GitHub[1], but it only has five entries. Moreover all of the crates in the file were audited by their respective authors - which kind of goes against the whole idea of this thing.<p>Overall GitHub seems to only have six audits.toml files[1], two of which are the Mozilla one mentioned above, the other four are empty.<p>[1] <a href="https://github.com/mozilla/gecko-dev/blob/64f3b7d019700f4fe3e5c033986bf7d20b49ba1c/supply-chain/audits.toml" rel="nofollow">https://github.com/mozilla/gecko-dev/blob/64f3b7d019700f4fe3...</a><p>[2] <a href="https://github.com/search?q=filename%3Aaudits.toml&type=code" rel="nofollow">https://github.com/search?q=filename%3Aaudits.toml&type=code</a>
Has there been any study of the effectiveness of code audits? Sensitivity and specificity in trying to find security problems, unintentional or intentional.
With out mandatory user fields optional or signed audits I wasn't convinced how useful this was. I originally read the post viewing this as a way of sharing audits amongst the general public, in similar fashion to how the packages themselves are distributed. However, once I RTFM[1] (well some of it at least) I realized that is not the intended use case and that I was mistaken.<p>tl'dr<p>* internal management of audits.<p>* reading audits in from trusted third parties.<p>I'm glad that someone is starting to tackle this terrifying problem.<p>[1] <a href="https://mozilla.github.io/cargo-vet/importing-audits.html" rel="nofollow">https://mozilla.github.io/cargo-vet/importing-audits.html</a>
If this does not have a way to track and filter based on who did the audit then it will wind up like the semantic web where anyone can tag a page with safeGoodQuality.
> A developer working on a function may suddenly discover the need to, say, left-pad a string with blanks. Rather than go though the pain of implementing this challenging functionality ...<p>The irony is palpable.
This feels like the equivalent of AdressSanitizer and similar tools for C. They fix a problem that shouldn't exist. At least not this extreme. C has the excuse of being old, Rust does not have that excuse. Using npm as an inspiration for cargo is just really sad.
> Our dependency tree has steadily grown to almost four hundred third-party crates, and we have thus far lacked a mechanism to efficiently audit this code and ensure that we do so systematically. (-Firefox)<p>Wow. This makes me feel like I have to stop using Firefox.<p>I wonder if others feel the same, or have a different analysis. For example, is the situation with Chrome better?