Lock the dependencies by committing the Cargo.lock about acmed HOT 1 CLOSED

https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries is very clear about recommending that all binaries should check in their Cargo.lock file. The requirement for frequent releases is there already in my opinion, because without them, people aren't going to rebuild acmed. If you assume they will rebuild acmed without a new release, then I'd say it'd also be fair to assume that they'd run cargo update before, to ensure that they get the newest dependencies.

With regards to analyzing all changes in all dependencies: I don't think that is feasible, ever, and even if it was, it's not related to checking in the Cargo.lock file IMO? There's cargo crev for this that works on a Web of Trust basis and operates on positive/neutral/negative assessments for crates, or lists of advisories on problematic crates/crate versions in the RUSTSEC database. IMO, working with cargo audit and the RUSTSEC database is enough here, and if we want to go the extra mile, we can do spot checks which we then document with cargo crev, but checking in the Cargo.lock file should be blocked on those things.

from acmed.