Cargo.lock files are published for libraries

[lfrancke]

While investigating a security audit warning I found that the hashes libraries (I didn't check all) publish a Cargo.lock file which fixes the dependencies.

I thought this was not recommended for libraries.

Is this done on purpose for the hashes libraries?

[newpavlov]

Hm, no it's not intended. I am not sure why lock files got included in the published packages. Configuration of this repository is similar to other repositories in this organization and at first glance other crates do not have this problem (I have checked aes v0.6, cmac v0.5, and some trait crates). Looking at the repository state from which one of problematic crates (sha2 v0.9.3) has been published, I don't see any suspicious differences. The only difference which I've noticed is that we specify [profile.dev] opt-level = 2 in root Cargo.toml of this repository, but I am not sure how would it result in publishing lock files by default.

@tarcieri
Any ideas?

[lfrancke]

Thank you for investigating.
I should have provided more details.
I looked at sha-1 in version 0.8.2 (and a few others) because it depends on block-buffer which in turn depends on generic-array which has a vulnerability https://rustsec.org/advisories/RUSTSEC-2020-0146.html

So we were eager to update generic-array and were surprised to find the Cargo.lock file.

[tarcieri]

I'm not sure why the Cargo.lock files got included, but regardless, it's orthogonal to your issue. AFAIK the only time they're used is with cargo install --locked (which only applies to [[bin]] crates)

[lfrancke]

Thanks @tarcieri - still learning a lot.
So far I always thought that having a Cargo.lock for a library would mean that those deps are being used.
In that case I'll have to continue my investigation.

[tarcieri]

The toplevel Cargo.lock file in your project will show the dependency resolution. You can also use cargo audit to lint for vulnerabilities.

[lfrancke]

Yep, cargo audit is what triggered all of this: fizyk20/generic-array#98
A new version has been released that fixes the issue.

That said: My confusion was because I didn't know about the different rules for 0.x.y versions where "x" is treated as "major" by Cargo.

Sorry for the noise, you were right that the Cargo.lock has nothing to do with my issue.
Not sure if you want to leave the issue open?

[tarcieri]

I think we can close it.

It appears that publish-lockfile is automatically set to true for any crate that has examples, which is probably what's going on. See:

rust-lang/cargo#5654