What does HackerNews think of cargo-geiger?

Detects usage of unsafe Rust in a Rust crate and its dependencies.

Language: Rust

Instead of looking at the crates themselves, you might want to check your (or others') Rust application with https://github.com/rust-secure-code/cargo-geiger to get a sense of effective prevalence. I also dispute that the presence of unsafe somewhere in the dependency tree is an issue in itself, but that's a different discussion that many more had in other sub-threads.
For that, I believe you need to use cargo-geiger[0] and audit the results.

[0] - https://github.com/rust-secure-code/cargo-geiger

Rust has a culture where people don't use `unsafe` unless absolutely necessary. That is generally good enough in my experience.

If you want to go further, you can disable unsafe in a crate by adding #[forbid(unsafe)].

And if you need more control than that, there's probably tooling out there that will help depending on what exactly you need.

https://github.com/rustsec/rustsec/tree/main/cargo-audit

https://github.com/rust-secure-code/cargo-geiger

https://github.com/crev-dev/cargo-crev

People do consistently audit unsafe usage. And I would rather have atrocious rust code that's memory safe, than atrocious C/C++ code that comes with a free package of CVEs.

There are tools that explicitly exist for this use case, such as cargo-geiger [0]. There was some drama with a large framework called Actix a while ago due to the maintainer having a bit of a cavalier attitude towards unsafe usage. Etc.

0: https://github.com/rust-secure-code/cargo-geiger

Interesting paper. Here's one of their key conclusions:

> Our analysis shows that while publicly available Rust libraries rarely use the unsafe keyword (even very popular libraries), most of them are still not Safe Rust, because of unsafe use in dependencies.

I think this might be a misapprehension of safety in Rust by the authors: safety doesn't mean that absence of the `unsafe` keyword in your dependency tree, it means safety by construction through safe wrappers of fundamentally unsafe code.

The Rust standard library is the perfect example of this: it exposes safe interfaces that are built on top of fundamentally unsafe OS primitives and system calls. That doesn't make any code that uses them "unsafe"; it parametrizes the notion of safety on safe abstractions. That's all Rust has ever promised, and it's still significantly better than the status quo.

Other than that, the paper's other observations are excellent: we should be more aware of the presence of `unsafe` in our dependency trees, and that information should be more readily surfaced by standard tooling. Tools like `cargo geiger`[1] and `siderophile`[2] (FD: my company's tool) bring us a little closer to that.

[1]: https://github.com/rust-secure-code/cargo-geiger

[2]: https://github.com/trailofbits/siderophile

There exist unofficial tools for counting the number of unsafe blocks in a project: https://github.com/rust-secure-code/cargo-geiger

However a sufficiently determined evil crate can use soundness holes (like fake-static) or macros (like plutonium) to misbehave without visible unsafe.

Related to what you are looking for is https://github.com/rust-secure-code/cargo-geiger which analyzes the dependency tree for unsafe but afaik it doesn't actually show each individual block.

The readme is quite good.

That's if you use 'Safe Rust', then the safety guarantees hold true. However, the risks increase as soon as you start using unsafe{} or import a crate that also has unsafe{} code which is why I like using cargo-geiger on my projects to see the unsafe{} uses in my code and dependencies [0]. Use unsafe{} at your own risk. [1]

[0] https://github.com/rust-secure-code/cargo-geiger

[1] https://arxiv.org/abs/2003.03296