RustConf 24/Audit Rust dependencies

From Legoktm

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
Retrieved from "https://legoktm.com/w/index.php?title=RustConf_24/Audit_Rust_dependencies&oldid=297"