On 2025-07-18 at 23:15:19, Ezekiel Newren wrote: > This goes against what I think is best practices. Don’t we need > Cargo.lock to audit and debug platform specific issues, and to ensure > reproducibility? Without Cargo.lock, we might get different results > one minute to the next if one of our dependencies releases a new > version. Checking in Cargo.lock aligns with Cargo’s documented best > practices (https://doc.rust-lang.org/cargo/faq.html#why-have-cargolock-in-version-control). I appreciate that, but best practices also don't limit software to a six-week lifespan. Rust the language is a great tool, but we also have a special case here in that we need to support software that upstream does not and that we care about OS distros, which upstream does not. Note that when someone builds locally, a Cargo.lock will be created and they will get reproducible builds from that point on. It is only on first build that they will get whatever's the latest. > I understand your concern and I agree that this could become a > problem. I’m totally flexible on which rust version should be used, > but without Cargo.lock checked in we lose the ability to audit why a > build failed. I think that this will be a pain point, but numbing that > pain means we can’t solve intermittent problems due to dependencies in > the future. I was one of the maintainers for Git LFS for several years. We routinely had people come to us and say, "This dependency you're using has a portion that you're not using, which has a CVE. I demand you update it and do a new release immediately because our security scanner is going off and our company policy is that there be no exceptions." This happens literally all the time and I absolutely in no case want to see those people on this list or the security list. So the options as I see them are (a) we don't check in Cargo.lock, (b) we convince the Rust project and the ecosystem to provide LTS releases with security fixes, or (c) we only accept dependencies that have our same lifetime policy (which are very few and far between). I know this makes builds unreproducible (although not under the Reproducible Builds project's definitions), but we really don't have many alternatives. -- brian m. carlson (they/them) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
