libp2p
Consider tracking `Cargo.lock` in Git
See the following discussion: https://github.com/libp2p/rust-libp2p/pull/2803#discussion_r956704249
TLDR: Tracking Cargo.lock would allow for greater visibility on how our dependencies change and might f.e. give us an earlier insight into bad semver bumps.
Another PoV worth considering is the visiblity from leaving .lock files in source tags / commit history to see what was used back in time given commit / release time to crates.io -
Let's say if you leave the old .lock to somewhere back in time you can audit back in history how things were built / what things were built with in precision.
However for plain security side of it in isolation there is better solution to this - cargo-auditable but that is further way on and nothing you can do as a library as it's more of a executable binaries thing that map everything together.
One downside is that you will get a lot of dependabot noise but IMO saying @dependabot merge blindly to everything is more valuable to me in this situation than just piling up invisible changes around that may come as a big shock in big bundle when I didn't screen them individually - e.g. there can be multiple deps (and code) that changed and it's not always clear what broke it until you find that dep that was supposed to bump semver with breaking change that is.
This would also give us better control over the caches in our CI setup.
It might be worth tracking a lockfile that is generated with cargo +nightly generate-lockfile -Z minimal-versions.
Here is another incident that currently blocks our CI: https://github.com/mcginty/snow/issues/146
I am taking this as an opportunity to resolve this issue to unblock our CI.