Cannot read new Cargo.lock files

[cod10129]

Cargo-geiger cannot read Cargo.lock files created by newer Cargo versions, which makes it unusable unless you use an older version of Cargo to generate a lockfile before running cargo geiger.

Repro

Install a version of Cargo >= 1.83, and cargo-geiger (tested on the latest release, 0.11.7).

cargo new geiger-test
cd geiger-test
cargo generate-lockfile
cargo geiger

Output:

error: Cargo("failed to parse lock file at: ~/geiger-test/Cargo.lock")

Expected output (reproducible if you use Cargo 1.82):

Metric output format: x/y
    x = unsafe code used by the build
    y = total unsafe code found in the crate

Symbols:
    🔒  = No `unsafe` usage found, declares #![forbid(unsafe_code)]
    ❓  = No `unsafe` usage found, missing #![forbid(unsafe_code)]
    ☢️  = `unsafe` usage found

Functions  Expressions  Impls  Traits  Methods  Dependency

0/0        0/0          0/0    0/0     0/0      ❓ geiger-test 0.1.0

0/0        0/0          0/0    0/0     0/0

[shinmao]

I also run into this issue with v1.84.0-nightly.

[oherrala]

Also can't read Cargo.toml workspace files with resolver = "3". This is also fixed by updating the cargo dependency.

resolver setting 3 is not valid, valid options are "1" or "2"

[meltyness]

For future readers, be advised that this sort of thing may have fallen out of vogue or usefulness.

"uses unsafe" is kind of an unreliable or vague heuristic.

You may be better off looking into "Miri" or "CHERI" to understand where your application is inheriting or exhibiting risk.

"Miri" and "CHERI" are referenced in the official docs, at the time of writing, in the context of comprehending consequences with unsafe code: https://doc.rust-lang.org/std/ptr/index.html

[shinmao]

@meltyness I am not sure what you mean. I think the users cargo-geiger already realize the risk of unsafe, and that's why this tool can help them find out the inherited unsafe. Do you mean this tool can't be used anymore?

[meltyness]

@shinmao
This bash one-liner will naively simulate geiger by looking for .rs files which show signs of unsafe code. It's naive in a way that may produce both false negatives and false positives, but also may serve as a fair heuristic for this.

cargo tree | grep -zP "$(grep -PR "fn unsafe|unsafe \{" ~/.cargo/ 2>/dev/null | cut -d":" -f1 | grep \.rs | cut -d"/" -f8 | perl -p -e 's/[-][0-9]+[.][0-9]+[.][0-9]+[+]?.*$//' | uniq | tr '\n' '|' | perl -p -e 's/\|$//' | perl -p -e 's/[|]/ | /g')"

I'm just saying there's more refined alternatives to this package, which might explain the delay in getting issues with it fixed.

Additionally, a look at other issues suggests that when this worked it ran every build script, which is it's own special kind of thing.

Anyway, I hope this helps!

[meltyness]

Here's a specific example about how this is maybe only servicing as a heuristic:

cargo-geiger/geiger/src/geiger_syn_visitor.rs

Line 126 in e2ddd16

// TODO: Visit macros.

Another solution that could be scripted out pretty easily is to individually cargo check each item in the dependency tree with RUSTFLAGS="-D unsafe_code" left as an exercise.

Obviously the preference towards more analytical solutions like CHERI and Miri mentioned earlier.