| Message ID | YeyhhR4Mxc+GzETW@jasmine.lan |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [bug#53461,kiasoc5@tutanota.com:,Rust,CVE] | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/comparison | success | View comparision |
| cbaines/git branch | success | View Git branch |
| cbaines/applying patch | fail | View Laminar job |
| cbaines/issue | success | View issue |
Hi Leo, Leo Famulari <leo@famulari.name> writes: > From: kiasoc5@tutanota.com > Subject: Rust CVE > To: guix-security@gnu.org > Date: Sun, 23 Jan 2022 01:20:10 +0100 (CET) (3 hours, 7 minutes ago) > > Hi, > > Rust has a new cve that is only mitigated by upgrading to Rust 1.58+. > > https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html > > Attached is a patch that adds rust-1.58.1. It doesn't replace the > default as I'm not sure whether this should be grafted or not. > > Thanks > kiasoc5 > >>From 753f4e9c68a7b12267989d1721e97841d9f499d0 Mon Sep 17 00:00:00 2001 > From: kiasoc5 <kiasoc5@tutanota.com> > Date: Sat, 22 Jan 2022 19:10:50 -0500 > Subject: [PATCH] gnu: Add rust-1.58. > > * gnu/packages/rust.scm (rust-1.58): New variable. > --- > gnu/packages/rust.scm | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/gnu/packages/rust.scm b/gnu/packages/rust.scm > index 5a6d4a5c30..c9b44da844 100644 > --- a/gnu/packages/rust.scm > +++ b/gnu/packages/rust.scm > @@ -784,6 +784,10 @@ (define rust-1.57 > `("procps" ,procps) > (package-native-inputs base-rust)))))) > > +(define rust-1.58 > + (rust-bootstrapped-package > + rust-1.57 "1.58.1" "1iq7kj16qfpkx8gvw50d8rf7glbm6s0pj2y1qkrz7mi56vfsyfd8")) > + The rust-1.57 variable should probably be made private or hidden now. Also, unless we rebuild all crates with rust-1.58, it seems to me like we won't be addressing the problem, as the CVE touches the 'remove_dir_all' procedure part of the standard library of Rust (and we all know Rust likes to build things statically). Am I missing something? Thanks, Maxim
On Sat, Jan 22, 2022 at 10:33:52PM -0500, Maxim Cournoyer wrote: > The rust-1.57 variable should probably be made private or hidden now. > > Also, unless we rebuild all crates with rust-1.58, it seems to me like > we won't be addressing the problem, as the CVE touches the > 'remove_dir_all' procedure part of the standard library of Rust (and we > all know Rust likes to build things statically). > > Am I missing something? I don't know about Rust things! I just forwarded this message from the private list to the public list.
Hi, Leo Famulari <leo@famulari.name> writes: > On Sat, Jan 22, 2022 at 10:33:52PM -0500, Maxim Cournoyer wrote: >> The rust-1.57 variable should probably be made private or hidden now. >> >> Also, unless we rebuild all crates with rust-1.58, it seems to me like >> we won't be addressing the problem, as the CVE touches the >> 'remove_dir_all' procedure part of the standard library of Rust (and we >> all know Rust likes to build things statically). >> >> Am I missing something? > > I don't know about Rust things! I just forwarded this message from the > private list to the public list. OK! I just asked in #rust and they confirmed what I thought (all crates -- well the ones using 'std::fs::remove_dir_all' but we can't easily know) needs to be rebuilt if we are to patch that CVE. Maxim
On Mon, Jan 24, 2022 at 04:31:25PM -0500, Maxim Cournoyer wrote: > OK! I just asked in #rust and they confirmed what I thought (all crates > -- well the ones using 'std::fs::remove_dir_all' but we can't easily > know) needs to be rebuilt if we are to patch that CVE. Okay. Let's see... ------ $ git grep cargo-build-system gnu/packages | wc -l 2152 ------ I suppose we could do it quickly on a branch.
Hello, Leo Famulari <leo@famulari.name> writes: > On Mon, Jan 24, 2022 at 04:31:25PM -0500, Maxim Cournoyer wrote: >> OK! I just asked in #rust and they confirmed what I thought (all crates >> -- well the ones using 'std::fs::remove_dir_all' but we can't easily >> know) needs to be rebuilt if we are to patch that CVE. > > Okay. Let's see... > > ------ > $ git grep cargo-build-system gnu/packages | wc -l > 2152 > ------ > > I suppose we could do it quickly on a branch. Note that Rust is now needed to build all of GTK, at least on x86_64. That's a rather large rebuild. Maxim
On Tue, Jan 25, 2022 at 06:06:55PM -0500, Maxim Cournoyer wrote: > > I suppose we could do it quickly on a branch. > > Note that Rust is now needed to build all of GTK, at least on x86_64. > That's a rather large rebuild. Oh, right. Well, I wonder what we should do?
Hello, Leo Famulari <leo@famulari.name> writes: > On Tue, Jan 25, 2022 at 06:06:55PM -0500, Maxim Cournoyer wrote: >> > I suppose we could do it quickly on a branch. >> >> Note that Rust is now needed to build all of GTK, at least on x86_64. >> That's a rather large rebuild. > > Oh, right. > > Well, I wonder what we should do? Perhaps a rebuild branch for it... but let's finish migrating to the new SSD storage first (we're still just copying part of /var/cache into it). This should give us some time to update the Rust chain to 1.58.1. Would you or anyone else like to try? It's nothing to difficult; it consists of moving the tests bits to 1.58.1 (the leaf package), and hide the previous versions (Rust only support the latest release). Then rebuild the world with it. We could use this opportunity to ungraft too. Thanks, Maxim
diff --git a/gnu/packages/rust.scm b/gnu/packages/rust.scm index 5a6d4a5c30..c9b44da844 100644 --- a/gnu/packages/rust.scm +++ b/gnu/packages/rust.scm @@ -784,6 +784,10 @@ (define rust-1.57 `("procps" ,procps) (package-native-inputs base-rust)))))) +(define rust-1.58 + (rust-bootstrapped-package + rust-1.57 "1.58.1" "1iq7kj16qfpkx8gvw50d8rf7glbm6s0pj2y1qkrz7mi56vfsyfd8")) + ;;; Note: Only the latest versions of Rust are supported and tested. The ;;; intermediate rusts are built for bootstrapping purposes and should not ;;; be relied upon. This is to ease maintenance and reduce the time