RustConf 24/Audit Rust dependencies

Notes from the RustConf '24 Unconference session about auditing Rust dependencies:

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