Report abomonation as unsound

[saethlin]

I'm a bit unsure where to go with this.

The abomonation crate is unsound in so many ways; though the interface is marked as unsafe it doesn't document all its requirements and contains probably-invalid implementations of its own unsafe Trait. The authors appear to know that this is all deeply problematic (most of the open issues on the crate are about various soundness problems), but the crate averages ~600 daily downloads on weekdays due to its use in nalgebra, whose tests for their abomonation implementations also fail for the same reasons.

[tarcieri]

This looks fine to me. The issue regarding unsoundness has been open for two years, so I think this warrants an informational advisory.

[Shnatsel]

Ah, I wanted to discuss our process for advisories without a fix, but I see I'm a little too late for this one. Welp, that's on me.

[tarcieri]

I left a comment about the advisory on the upstream issue. Apologies for not giving them a heads up in advance.

[frankmcsherry]

Drive by, but afaict there is no unsoundness in the crate. Perhaps there was at the time the issue was filed, but the only definition I've seen is "exposes undefined behavior to safe code", which the crate does not do. Happy to keep the advisory (no responsible person should use the crate), but wanted to flag that the details seem like they may be incorrect (and, there may be other, more defensible crates where the distinction is important).

More importantly, I think, what you want to track down are the crates that use abomonation, specifically without declaring their uses of it unsafe. Those crates would be unsound (for example, timely dataflow used to do this, but has since stopped).

The concern about bypassing ASLR seems a bit mysterious, given that the core Rust library allows you to do this.

println!("{:p}", "am i a cve?");

No action items from me; please keep reporting the crate as bad, but preferably also go and flag the folks using it! There's at least one fork (not mine), to boot!