https://legoktm.com/w/index.php?action=history&feed=atom&title=RustConf_24%2FAudit_Rust_dependenciesRustConf 24/Audit Rust dependencies - Revision history2026-04-19T12:55:52ZRevision history for this page on the wikiMediaWiki 1.39.17https://legoktm.com/w/index.php?title=RustConf_24/Audit_Rust_dependencies&diff=297&oldid=prevLegoktm: new page2024-09-16T17:23:19Z<p>new page</p>
<p><b>New page</b></p><div>Notes from the RustConf '24 Unconference session about auditing Rust dependencies:<br />
<br />
* Half of Fuschia is third-party code<br />
** Rigorous auditing of Rust code, <br />
** uses cargo-vet, safe-to-deploy, etc.<br />
** unsafe review for all crates, no unsoundness, guidelines on how to review unsafe at 5 levels<br />
*** async Task is incredibly complicated, took longer than 10x bigger and more unsafe crates<br />
** want better ways to audit dependencies<br />
* zcash uses cargo-vet, also depends on Fuschia's reviews<br />
** cryptographic audits specifically<br />
* Google (not Fuschia) has its crypto people review any crypto code<br />
* solarwinds (also xz-utils) really kicked off discussion of supply chain attacks<br />
* cargo-crev (GPG-style web of trust) and cargo-vet<br />
* is anyone auditing C libraries/native code that people depend upon?<br />
** ocassionally have to audit inline assembly (ring?)<br />
*** is this better than openssl? (uses perl for assembly generator)<br />
* do we have a way of marking negative reviews?<br />
** not in cargo-vet<br />
** also need to mark skipping specific targets and featuresets<br />
*** e.g. pull in nix crate, 50% of it is super exotic OSes like PlayStation Vita<br />
** e.g. a crate was approved as long as you set a "no-unsafe" flag<br />
** we can add comments, but that breaks down cargo-vet's mechanical<br />
* ongoing.dev - *who* is in your dependency graph<br />
** anonymous and drive by contributors are not necessarily bad<br />
** a crate is in a group, you can see who has reviewed but not necessarily who all is in a position to inject code<br />
** would like to look at source tree to see if e.g. "Jia Tan" contributed anything<br />
* crates.io are just zipped up source, cannot reliably go from crates.io to a tag in a git repo<br />
** there's a .vcs-info file, generates hash of the commit checked out during publish<br />
** questionable provenance<br />
** there's a new RfC open for trusted publishing with OIDC, trust github<br />
*** people also publish their own code on random git hosts which don't have OIDC<br />
*** would knockout 80%-ish<br />
** no guarantee there's a VCS repository<br />
** new cargo includes a dirty=true<br />
* another RfC in progress about improving provenance<br />
* any difference in publishing and source is already a red flag<br />
* in previous cargo session, discussion about how ring/aws-lc ship object files so windows users don't need nasm<br />
** should be done reproducibly, but automated, no one wants to do it by hand<br />
* Fuschia checks-in generated code, sometimes reviews generator or generated, will cross-reference the two.<br />
* how much do you review unsafe?<br />
** in SecureDrop, small team, just look for a comment that makes logical sense<br />
** using a crate is trusting people and their expertise, if you're gonna read all the docs, etc. then you could just write it yourself<br />
*** Actually that's what Google does, read MS docs and blogs to understand, etc.<br />
*** Found a bug in socket2 this way regarding null terminated strings<br />
* easily-nerd sniped people who do reviews, often end up more thorough than needed<br />
* at Google, aspiring to make the bar for unsafe Rust to be higher than C/C++<br />
** need better tooling for unsafe Rust. Code review tools aren't suited to this kind of review<br />
** Want easy tool to upstream // SAFETY comments (median crate will say "thank you that's awesome"!)<br />
** no guide to understand and audit unsafe Rust.<br />
*** need comphreensive unsafe rust guide<br />
*** nominomicon is a dictionary<br />
** had to fight the perception that unsafe Rust is worse than C/C++ (which there's a sanitizer for)<br />
** touching a file with unsafe Rust triggers an unsafe reviewer<br />
* semgrep rule to find unsafe blocks/code<br />
** maybe bigger scope e.g. if safe code has a necessary invariant<br />
* room for a different FFI dialect? in between safe and unsafe<br />
** still fully unsafe because C, but makes reviewing easier with condition that you trust underlying C library<br />
** a suite of macros for unsafe FFI, just need to verify the macro is invoked correctly<br />
* do you use miri in unsafe reviews? would like to but it doesn't work if you have FFI<br />
* a Rust ubsan would be nice (apparently rustc supports this on some platforms)<br />
** an edge/FFI sanitizer<br />
* nix gives us the safe bindings, if we had safe bindings for everything that would be fine<br />
** scaling that up to every FFI needed for every library is unsolved<br />
* crates that use 10 windows functions and generate their own bindings instead of using the heavy windows crate<br />
** also some other crate in your dependency tree is going to have the heavy crate anyways, so you've now duplicated stuff<br />
* process?<br />
** just go file by file, can mostly eyeball safe Rust (exception: crypto code), harder to do that for unsafe Rust<br />
*** auditing crypto requires a person good with unsafe Rust and crypto (often not the same person!)<br />
* easier to go C -> Rust than Rust -> Haskell, hope community starts to look at effects<br />
** can write code like that, but need to also audit for effect safety<br />
* (what if: unsafe was a value instead of a keyword?)<br />
* sunfishcode (does WASI stuff) has a mirror of std fs/net/etc. that is based on sandboxed capabilities<br />
* need to spend more man-hours on improving cargo-vet (less than expected forward dev from Mozilla) - get in touch</div>Legoktm