Report unsoundness in cve-rs, totally-safe-transmute and totally-safe

[Nugine]

We are using cargo audit -D warnings to avoid problematic dependencies.

To prevent anyone from using these crates in the dependency tree (accidentally?), I think it is meaningful to include them in advisories.

• https://github.com/meithecatte/fake-static (RUSTSEC-2020-0013)
• https://github.com/Speykious/cve-rs
• https://github.com/ben0x539/totally-safe-transmute
• https://github.com/viktorlott/totally-safe

Reverse dependencies

• https://crates.io/crates/cve-rs/reverse_dependencies (0 dependents)
• https://crates.io/crates/totally-safe-transmute/reverse_dependencies (1 dependent)
• https://crates.io/crates/totally-safe/reverse_dependencies (0 dependents)

resolves #826

[tarcieri]

See previous discussion on #826

[Nugine]

The three crates are intentional exploits of rustc soundness bugs, like fake-static, which has been flagged in #207 and #270 previously. I personally recommend including them as informational = "unsound".
If RustSec cannot make a decision yet, I'm Ok to leave this PR open and wait.

[kornelski]

These crates may be a joke, but the APIs are unsound for real. I expect cargo audit is used in projects where ending up with any of them as a dependency isn't funny. I would prefer to have them flagged.

[riking]

I think some new common vocabulary here might be helpful - perhaps "[crate] is intentionally unsound" with keyword=["intentionally-unsound", "compiler-bug"] ?

[djc]

I think some new common vocabulary here might be helpful - perhaps "[crate] is intentionally unsound" with keyword=["intentionally-unsound", "compiler-bug"] ?

I like this suggestion.

[fintelia]

I wonder if something along the lines of "exploit-demo" would be a better tag. The crates are all demonstrations of unsoundness caused by other software (either rustc or the standard library) which work by exposing a clearly unsound API while using no unsafe code themselves.

[djc]

I wonder if something along the lines of "exploit-demo" would be a better tag. The crates are all demonstrations of unsoundness caused by other software (either rustc or the standard library) which work by exposing a clearly unsound API while using no unsafe code themselves.

Maybe unsound-demo, then?

[tarcieri]

I think "soundness hole" is the typical term for these

[fintelia]

These crates do not contain a soundness hole. Rather, they're demonstrations that a soundness hole exists in the compiler/standard library.

[tarcieri]

Yes, I was suggesting they exploit a soundness hole

[djc]

Thanks!

[fintelia]

Having the category be "unsound" and the keyword "soundness-hole" in the advisory makes it sound to me like these are saying that the crates themselves contain soundness holes. Further, the advisory text lacks any discussion that these are demonstrations and not intended for use by other crates. In fact, restating the satirical content of those crate's documentation provides the exact opposite impression. It would be very easy to interpret these advisories as disparaging the crate authors

[djc]

Having the category be "unsound" and the keyword "soundness-hole" in the advisory makes it sound to me like these are saying that the crates themselves contain soundness holes. Further, the advisory text lacks any discussion that these are demonstrations and not intended for use by other crates. In fact, restating the satirical content of those crate's documentation provides the exact opposite impression. It would be very easy to interpret these advisories as disparaging the crate authors

A PR revising the text in a direction you find more appropriate would be welcome.

[tarcieri]

@fintelia how can a crate introduce a soundness hole? Isn't that definitionally impossible as soundness holes are a property of the language?

[Nugine]

Having the category be "unsound" and the keyword "soundness-hole" in the advisory makes it sound to me like these are saying that the crates themselves contain soundness holes. Further, the advisory text lacks any discussion that these are demonstrations and not intended for use by other crates. In fact, restating the satirical content of those crate's documentation provides the exact opposite impression. It would be very easy to interpret these advisories as disparaging the crate authors

If you can trigger UB without using any unsafe API from a library, then the library is unsound. These crates are unsound even though the holes are "re-exported" from rustc.

These demonstrations should not be published to crates.io if they are really not intended for use by other crates.

I don't think copying the introduction of these crates makes it satirical to the crate authors.

[fintelia]

@fintelia how can a crate introduce a soundness hole? Isn't that definitionally impossible as soundness holes are a property of the language?

I don't know the precise definition, but there's no language level issue involved in totally-safe-transmute. It merely demonstrates that the unsafe blocks used to implement std::fs::File aren't actually sound, because operating on /proc/self/mem can violate soundness. The reason I'm arguing is because there's probably thousands of crates that behave unsoundly if you pass in /proc/self/mem as a path argument. Rustsec does not and should not issue advisories for all of them.

As a side note, did anyone reach out to the crate authors to ask about phrasing or what they think about these advisories?

[djc]

@Speykious, @ben0x539, @viktorlott any comments/suggestions?

[ben0x539]

Hi I'm the totally-safe-transmute author. I appreciate the throughtful discussion in this thread over my silly joke crate. I'm currently not using rust in production so I happily defer to others' expectations that cargo-audit warns them if someone genuinely pulls in totally-safe-transmute.

I would appreciate it if the wording of the advisory included some indication that the crate is doing a bit and as such wasn't meant to be used in real code, and that's why it will not have patched versions. I acknowledge I didn't exactly bother explicitly giving any such indication either, but then again my target audience was rust programmers with extra time on their hands and not consumers of advisories from an automated system who did not sign up for divining intent from context clues.

If you were to put something like "This crate is a toy and should never be used" I think I should be perfectly satisfied, and I think it would also be good information for advisory consumers, since, like, the problem that someone is pulling toy code into your production dependency tree is distinct from the problem that that code is sketchy. I suppose it doesn't actually come up a lot or there would be a tag for it already.

These demonstrations should not be published to crates.io if they are really not intended for use by other crates.

Yeah I suppose I never had a good reason for posting to crates.io beyond roleplaying as a real crate. I apologize to anyone who's had extra headaches at work because of me having a fun time with my silly code.

[djc]

If you were to put something like "This crate is a toy and should never be used" I think I should be perfectly satisfied, and I think it would also be good information for advisory consumers, since, like, the problem that someone is pulling toy code into your production dependency tree is distinct from the problem that that code is sketchy. I suppose it doesn't actually come up a lot or there would be a tag for it already.

Want to submit a PR along these lines?

[Speykious]

I saw some discussion above about the utility of restating the project's satirical description. I don't have much of anything to suggest in regards to this PR, but if someone makes a PR in the future and wants to change the descriptions, I propose:

`cve-rs` provides demonstrations of common memory vulnerabilities (such as buffer overflows and segfaults) implemented completely within safe Rust.

I'm fine either way. That being said, I don't have much experience using Rustsec (I probably should).

[djc]

For you too: a PR making this change would be great!