Re: [PATCH 1/7] xdiff: introduce rust

[Ezekiel Newren <ezekielnewren@gmail.com>]

On Wed, Jul 23, 2025 at 3:57 PM brian m. carlson
<sandals@crustytoothpaste.net> 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?