On Wed, Jul 23, 2025 at 3:57 PM brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > > 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 I like having the Cargo.lock file to figure out why a build worked on one system, but not another. After talking with Elijah I've decided that a good solution would be to add Cargo.lock to .gitignore and change the github workflows to ensure that Cargo.lock is preserved for all builds. We should also add a comment to Cargo.toml stating that any build or test issues should include the Cargo.lock that was generated when asking for help. What does the community think of this solution?
