Skip to content
Auditing crates for unsafe code which can be safely replaced
Branch: master
Clone or download
Shnatsel Merge pull request #48 from xtian/patch-1 Fix markdown for nested lists
Latest commit 264982b Nov 2, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information.
img Initial commit Jul 11, 2019 Add Apache 2.0+MIT licenses; Rust Code of Conduct Jul 22, 2019
LICENSE-MIT Add Apache 2.0+MIT licenses; Rust Code of Conduct Jul 22, 2019 Fix markdown for nested lists Nov 2, 2019

Rust Safety Dance


This is a place for people to communicate about auditing unsafe code in core Rust crates and replacing it with safe code where feasible.

Everyone is invited to participate!

You do not have to be an unsafe expert to help out. There's a lot of work to do just picking crates (ones with a lot of reverse-dependencies are best), and then sorting out where they use unsafe and why. If you think something isn't right just post it in the tracking issue and others can have a look and talk it out.


Our process is as follows:

  1. File a tracking issue in this repo about a particular crate, giving its name and a link to their github (or other repository location).
  2. Audit unsafe usage in that crate.
    • This is easy to start! Note that the GitHub search isn't very good, so it's best to clone the project and use an editor on your own computer. The cargo geiger command can also help here.
    • Once you know where the unsafe blocks are it gets harder: you have to carefully determine if the unsafe is being used appropriately. We've been requesting Clippy lints for known antipatterns, so running cargo +nightly clippy is a good starting point. If you don't know if a certain unsafe block is okay, post the questionable block in a comment in the tracking issue here and someone else can have a look too, or ask in #black-magic on Rust Community Discord.
  3. When problems are found with an unsafe block we want to file bug reports in that crate's repo, send PRs with fixes if possible, and also write up security advisories if necessary.
    • If the unsafe block is sound, but can be converted to safe code without losing performance, that's a great thing to do! This is often the case thanks to Rust adding new safe abstractions and improving the optimizer since the code was originally written.
    • It's possible that unsafe can't be eliminated without a performance loss. Unfortunate, but it will happen some of the time. Note that benchmarks must actually be used to back up any performance loss claims. There are already many cases where switching from unsafe to safe alternatives has increased performance, so simply guessing that performance will regress is not enough.
    • If switching away from unsafe is impossible because of missing abstractions then that's important to know! We can work on improving the language, the standard library, and/or the ecosystem until the necessary gaps are filled in.
  4. Once a crate has been gone over enough we close that issue. If the crate needs re-checking again later on we just open a new issue.
  5. (Optional) If you have completely cleansed a crate of unsafe, add a #![forbid(unsafe_code)] attribute to its src/ or After doing that, help others discover Safety Dance by adding a badge to your unsafe forbidden

Markdown code:

[![unsafe forbidden](](

🏆 Trophy Case 🏆

Check out the safety improvements already done!


GIF image encoder/decoder written in Rust (tracking issue)

  • Unsafe blocks before: 6 (ignoring C API)
  • Unsafe blocks after: 2 (ignoring C API)

100% safety blocked by Polonius integration in rustc

Done by: Shnatsel


A streaming compression/decompression library DEFLATE-based streams in Rust. Has C and Rust backends (tracking issue)

  • Unsafe blocks before: 21 (when using Rust backend)
  • Unsafe blocks after: 2 (when using Rust backend)
  • Switched to using Rust backend by default (see miniz_oxide below)

Done by: oyvindln, Shnatsel, Alex Crichton


Image operations and conversions to/from image formats (tracking issue)

  • Unsafe blocks before: 21 (many of them unsound)
  • Unsafe blocks after: 6
  • Security bug fixed: RUSTSEC-2019-0014

The remaining unsafe blocks are inherent and cannot be removed. They have been audited and found to be sound.

Done by: fintelia, HeroicKatora, 64


Popular DEFLATE compression/decompression library (tracking issue)

  • Unsafe blocks before: 16 (4 of them unsound)
  • Unsafe blocks after: 1 plus 2 more moved to shared crates
  • Security bug fixed: RUSTSEC-2019-0010

100% safety blockers: rust-lang/rust#59229, rust-lang/rfcs#2714

Done by: DevQps, Shnatsel, WanzenBug


The fastest DEFLATE compression/decompression library in Rust, backend for flate2 (tracking issue)

  • Unsafe blocks before: 28 (2 of them unsound)
  • 100% safe code now - while being faster than the C version!
  • Potential security issue fixed: Frommi/miniz_oxide#36 (unclear if exploitable or not)

Done by: Shnatsel, oyvindln


A spinlock for Rust (tracking issue)

  • spin::RwLock found to be unsound,completely rewritten based on Facebook's Folly implementation, new implementation audited for soundness
  • Security bug fixed: RUSTSEC-2019-0013

Done by: 64, xacrimon

spin::Once still needs to be audited for soundness, see tracking issue

We need your help!

You can help by:

  1. Nominating crates for auditing - we're looking for widely used crates with unsafe in them
  2. Auditing nominated crates for soundness
  3. Replacing unsafe code with safe code where possible (where not possible - documenting why)
  4. Inspecting crates that have been made safer and requesting Clippy lints for the antipatterns discovered

Check out what's in progress or pick up a work item on the issue tracker!

You can’t perform that action at this time.