Skip to content

totally-safe-transmute is totally unsafe #826

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
sanxiyn opened this issue Mar 17, 2021 · 9 comments · May be fixed by #2221
Open

totally-safe-transmute is totally unsafe #826

sanxiyn opened this issue Mar 17, 2021 · 9 comments · May be fixed by #2221
Labels
Unsound Informational / Unsound

Comments

@sanxiyn
Copy link

sanxiyn commented Mar 17, 2021

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.

@tarcieri
Copy link
Member

tarcieri commented Mar 17, 2021

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.

@Lokathor
Copy link

Lokathor commented Mar 18, 2021

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.

@SoniEx2
Copy link

SoniEx2 commented Mar 26, 2021

Please don't, we use this in production!

@tarcieri
Copy link
Member

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 {
      [...]
   }
}

@SoniEx2
Copy link

SoniEx2 commented Mar 26, 2021

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

@RalfJung
Copy link
Contributor

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

@sanxiyn
Copy link
Author

sanxiyn commented Sep 29, 2022

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

@SoniEx2
Copy link

SoniEx2 commented Sep 29, 2022

have you looked at that dep tho. 😅

@Nugine
Copy link
Contributor

Nugine commented Feb 11, 2025

The only reverse dependency datafu = "0.0.7" does not actually use totally-safe-transmute. I confirmed via git clone and simple search.

So no one is using totally-safe-transmute seriously.
We can and we should flag it, since all versions of this crate are unsound.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Unsound Informational / Unsound
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants