cargo-geiger icon indicating copy to clipboard operation
cargo-geiger copied to clipboard

cargo-geiger does not detect use of `unsafe_code = "forbid"` in `Cargo.toml`

Open hashcatHitman opened this issue 8 months ago • 3 comments

In the Cargo.toml at the root of my project, I have the following defined:

[lints.rust]
unsafe_code = "forbid"

To my understanding, this is equivalent to #![forbid(unsafe_code)]. However, when I run cargo geiger in my project, it reports:

No `unsafe` usage found, missing #![forbid(unsafe_code)]

Is this the expected behavior? Is it preferable to use the in-source version for some reason?

hashcatHitman avatar Apr 11 '25 11:04 hashcatHitman

Needs to be added - want to work on it?

pinkforest avatar Apr 14 '25 01:04 pinkforest

Sure, I'd be happy to give it a shot.

hashcatHitman avatar Apr 14 '25 01:04 hashcatHitman

I've got it figured out where I can detect the root manifest and make a decision based on that, but the current issue is it applies to all crates - dependencies included. Looking for some advice.

My current implementation involves defining a new function, [cargo_geiger::scan::default::manifest_override], which takes a mutable reference to cargo_geiger_serde::report::UnsafeInfo (among a few other things). I decided to go with this approach largely because making this change directly in cargo_geiger::scan::unsafe_stats would change the signature in a way where I couldn't figure out how to update the existing tests to accommodate it.

I use cargo::util::toml::read_manifest to read the manifest of the root package, which I can access through cargo_geiger::mapping::CargoMetadataParameters to find the std::path::Path required and cargo::util::context::GlobalContext to get the cargo::core::source_id::SourceId required.

The two places it ends up needing to be called are cargo_geiger::format::table::handle_text_tree_line::text_tree_line_package_to_table_line_string and cargo_geiger::scan::default::scan_to_report

  • Is there a means to access the manifest for the current crate in the scanning process? If not, this should probably only apply to local crates. That said...

  • Even if only applying to local crates, I'd need a way to make sure the crate currently being scanned is actually related to the manifest I found. I have access to the cargo_geiger_serde::package_id::PackageId of the crate being processed, but I only have the cargo::core::package_id::PackageId of the manifest, which does not seem to be equivalent, nor have I found a way to convert between them. What would be the solution here?

hashcatHitman avatar Apr 16 '25 18:04 hashcatHitman