GNU bug report logs - #36841
[PATCH] build/cargo-build-system: Patch cargo checksums.

Previous Next

Full log

View this message in rfc822 format

From: Ivan Petkov <ivanppetkov <at> gmail.com>
To: Efraim Flashner <efraim <at> flashner.co.il>
Cc: 36841 <at> debbugs.gnu.org
Subject: [bug#36841] [PATCH v3] build/cargo-build-system: Patch cargo checksums.
Date: Wed, 31 Jul 2019 20:00:00 -0700

[Message part 1 (text/plain, inline)]

Hi Efraim,

> On Jul 30, 2019, at 3:46 AM, Efraim Flashner <efraim <at> flashner.co.il> wrote:
> 
> This one I'm pretty happy with. The checksums are only generated twice
> when there's a Cargo.lock file present and I've factored out the
> function to generate all the checksums. When that's moved to (guix build
> cargo-utils) it can be used by the rust compilers and icecat.

Overall the patch makes sense to me!

However, I am curious what are some of the situations in which you’re encountering
a Cargo.lock file? In a system like guix which maintains all dependencies immutably
and consistently, the Cargo.lock file is virtually useless (in fact it *could* be harmful
if an application is released with a Cargo.lock file pinning to a particular vulnerable
dependency which needs to be updated, requiring patching of the Cargo.lock file).

I’d be willing to go as far as suggest we unconditionally delete any Cargo.lock file
in source tarballs and let cargo generate its own replacement using the vendor
directory we have supplied. (Imports from crates.io <http://crates.io/> also never include a Cargo.lock
file, so this may only pertain if we’re performing a direct source import…)

—Ivan

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.