advisory-db

advisory-db copied to clipboard

Just in case someone uses https://crates.io/crates/totally-safe-transmute, let's have a permanent advisory against it so that cargo-audit can flag it.

There's been quite a bit of discussion in the past about these sorts of crates and whether they deserve advisories or not.

Case example: discussion of plutonium on #275.

I think it might be okay to file an informational notice of some sort, possibly notice or maybe unsound.

Curious what others think.

You can do the same thing if you run the program in a debugger that changes the memory while the program is paused. Or if someone uses LD_PRELOAD. Or any other number of things. All of rust collapses when you can't trust the memory to be consistent. The worst that you can really say about it is that it's giving you a footgun to speed up the process.

That said, you should be carefully vetting your dependencies, and the point of the advisory system is to make that vetting easier, so we should naturally have an advisory about this crate.

Please don't, we use this in production!

Coming from the perspective of perhaps a bit of a prankster myself....

I think there are good reasons to differentiate totally-safe-transmute from plutonium which I previously cited as "case precedent" for these sorts of crates.

Specifically plutonium is a procedural macro. I'd personally consider it "expected" that a procedural macro can inject unsafe. Perhaps that's a problem that should be tamed, but that's orthogonal to how to consider advisories filed against these kind of joke/art/provocative crates today.

totally-safe-transmute implements an unsound API. It does it in a circuitous way, to comedic effect, but from a vulnerability classification perspective I don't think we should treat it any differently from any other crate which contains code resembling the following:

pub fn quote_unquote_safe_fn_with_unsound_impl(...) {
   unsafe {
      [...]
   }
}

totally-safe-transmute should just optimize to a panic once llvm fixes the noalias stuff and rust stops emitting noalias-breaking async stuff.

noalias and async have absolutely nothing to do with it. Totally-safe-transmute is using /proc/self/mem.

I note that totally-safe-transmute now has one reverse dependency, so this is not theoretical.

have you looked at that dep tho. :sweat_smile: