Take cargo-geiger to the web

[Vagelis-Prokopiou]

Hi cargo-geiger community.

I am the creator of https://unsaferust.org. The reasons I created it are pretty match the same reasons you created cargo-geiger. So, I was wondering if we could join forces and take cargo-geiger to the web.

What I envision, is capturing the output of cargo-geiger (or a summary of the output) and show it on each crate's details page.

This way we can have a very easy and quick reference regarding the usage of unsafe per crate, and the the total usage of unsafe and all its dependencies, per crate.

I also intent to add a chart per crate, showing the progression (or regression) of unsafe usage over time.

Waiting on your thoughts :-)

[tarcieri]

What might be interesting if you were willing to offer it as-a-service is a way to generate a cargo geiger badge for your project, or an image-based report that can easily be embedded in things like README.mds

[Vagelis-Prokopiou]

This is an interesting suggestion. But I would consider it as a secondary goal.
My primary goal for now is to provide the cargo-geiger info through the web (interface).

[8573]

I wonder whether it would be more practical to have this information in lib.rs, where it already shows crev reviews, rather than a separate website.

cc @kornelski

[Vagelis-Prokopiou]

I agree. A single resource would be even better. Is there a way to include @kornelski in the discussion without directly contacting him?

[kornelski]

I'm sorry, but I think information provided by cargo-Geiger is misinterpreted by most people to mean more than it possibly can, resulting in needless doubt about good crates and a false sense of security about malicious crates. Therefore, I'm afraid it's a disservice to promote this information.

The problem is that Geiger looks at unsafe blocks, but not at injection of non-safe code in general, which can be done using several other language features as well as soundness bugs in the compiler. Catching all these cases is very difficult, and Rust is just not prepared to give such guarantees. Unfortunately, without this it's only a false sense of security. Malware may even intentionally inject unsafe code using one of the other loopholes to get a misleading "all safe" badge from cargo-Geiger, so an attempt to show "at least something" can be worse than nothing.

[Vagelis-Prokopiou]

injection of non-safe code in general, which can be done using several other language features as well as soundness bugs in the compiler

@kornelski regarding the points above, I would suppose you are referring to the points you raised here? https://internals.rust-lang.org/t/about-supply-chain-attacks/14038/6

Do you have any suggestion at all in mind, about addressing these issues? From your comment in the link above, it seems that it is not doable at all.

[alilleybrinker]

In general I think things like this are trying to expand the definition of unsafe beyond what it was designed for, in ways more likely to confuse or mislead people.

The construct of unsafe code is defined in terms of Rust’s safety model, and is not about security boundaries of applications, but about permitting code which Rust’s safety model can’t statically determine to uphold Rust’s key safety invariants. Safety does not equal security.

In the context of the safety model, you are generally assuming trusted contributors, with the goal of the model being to encourage safe code by default to benefit from Rust’s safety guarantees, and when that isn’t enough, to keep the scope of the unsafe code limited to make auditing easier. It does not make sense to extend this to a potential upstream dependency’s malicious contributor.

[8573]

Malware may even [...] get a misleading "all safe" badge from cargo-Geiger

a potential upstream dependency’s malicious contributor

I guess the core charges here are

1. that people turn to cargo-geiger to answer their question "Should I trust this dependency?" and
2. that cargo-geiger cannot answer that question.

I wonder whether it would be agreeable for the README explicitly to recommend considering rust-secure-code/cargo-supply-chain as an element of the process of answering that question, potentially helping to divert such users away from cargo-geiger.¹

Footnotes

1. It would be nice if cargo-supply-chain were integrated into cargo-deny as mentioned in https://github.com/rust-secure-code/cargo-supply-chain/issues/8² (with an option to ignore crates if their versions are pinned), but IIRWIIR 🙂. ↩

2. maybe better as a library, like rustsec, than by consuming JSON output ↩