Wildcard version warnings generated git dependencies with fixed commit

[TimJentzsch]

Describe the bug

When specifying a git dependency with a rev (i.e., fixed commit hash) entry, the version wildcard warning is triggered.
However, because of the commit hash, an exact version has been specified.

To Reproduce
Steps to reproduce the behavior:

1. Add a git dependency with a commit specified, e.g.:

   [dependencies]
   bevy_ecs_tilemap = { git = "https://github.com/StarArawn/bevy_ecs_tilemap", rev = "2967a394dc59c29fac14cb8cb187d601ea604a1e" }

2. Ban wildcard dependencies in deny.toml:

   [bans]
   wildcards = "deny"

3. Run cargo deny check. A wildcard error is triggered for the git dependency.
   In our case, it looks like this (with two git dependencies):

   error[wildcard]: found 3 wildcard dependencies for crate 'emergence_lib'
     ┌─ /home/tim/Documents/bevyengine/Emergence/emergence_lib/Cargo.toml:2:1
     │
   2 │ bevy-trait-query = '*'
     │ ^^^^^^^^^^^^^^^^^^^^^^ wildcard crate entry
   3 │ bevy_ecs_tilemap = '*'
   4 │ bevy_ecs_tilemap = '*'
     │ ^^^^^^^^^^^^^^^^^^^^^^
     │ │
     │ wildcard crate entry
     │ wildcard crate entry
     │
     = emergence_lib v0.1.0
       └── emergence_game v0.1.0
   
   

Expected behavior

The wildcard warning is only triggered for git dependencies if the commit hash is not fixed, i.e. when the rev attribute is missing.

Device:

• OS: Linux (Pop!_OS)
• Version 0.13.5

[Jake-Shadle]

This was fixed in #487

[TimJentzsch]

I'm still getting the same error with cargo-deny 0.13.6, is that intentional?

[Jake-Shadle]

Sorry, thought this was fixed, I guess I need another edge case when git dependencies are direct like that instead of a patch on top of a version, which is the only way I use them.

[BatmanAoD]

I believe I'm seeing this error, or a related one. I have a private package that is importing some other private packages from GitLab. Even with allow-wildcard-paths, I get this message:

error[wildcard]: found 2 wildcard dependencies for crate 'behavioral-tests'. allow-wildcard-paths is enabled, but does not apply to public crates as crates.io disallows path dependencies.

There's no indication of why cargo deny thinks there's a "public crate" involved here; is it saying that the two packages I've specified as git dependencies are public, or that the top-level package is public?

[kpreid]

There's no indication of why cargo deny thinks there's a "public crate" involved here

I took a look, and the code producing that error message doesn't actually check whether the allow-wildcard-paths option affected the result, just that you had it enabled. The actual reason for the failure is that whether or not the package is private, the git dependency doesn't count as a path dependency, and doesn't have any version requirements, so the wildcard ban always rejects it and can't be configured otherwise.

I created a PR #599 which changes the behavior to treat git dependencies like path dependencies, which seems like the cleanest solution short of larger changes to how the ban works and is configured.

[BatmanAoD]

@kpreid That looks like exactly what I hoped for from that option! Thanks!