GNU bug report logs -
#43173
Ensure that the correct linux-libre deblobbing scripts are used
Previous Next
Reported by: Leo Famulari <leo <at> famulari.name>
Date: Wed, 2 Sep 2020 18:30:02 UTC
Severity: normal
Done: Leo Famulari <leo <at> famulari.name>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 43173 in the body.
You can then email your comments to 43173 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
guix-patches <at> gnu.org
:
bug#43173
; Package
guix-patches
.
(Wed, 02 Sep 2020 18:30:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Leo Famulari <leo <at> famulari.name>
:
New bug report received and forwarded. Copy sent to
guix-patches <at> gnu.org
.
(Wed, 02 Sep 2020 18:30:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
In recent discussions [0], people raised the possibility that we might
accidentally leave non-free firmware blobs in our linux-libre packages.
If I understand correctly, the root of the issue is that, currently, we
manually specify the versions of the deblobbing scripts. They are not
changed with every linux-libre release, so it is usually okay to use an
older version number — the scripts themselves will be identical.
However, sometimes the scripts do change, and we might not notice, and
thus we would fail to remove every blob from the kernel sources.
These two patches should make that failure mode impossible, by 1) making
sure that the file names of the deblobbing scripts' store items include
the full version number of the kernel and 2) only defining the version
in one place. The hashes of the deblob scripts will be checked
automatically when Guix downloads them for each new kernel release.
I had to move the linux-libre-nnn-version variables to an earlier part
of the file, so that they are defined when referenced in the
deblob-scripts-nnn procedures. I regret changing the way this code is
organized... your advice is welcome!
[0] https://lists.gnu.org/archive/html/guix-devel/2020-08/msg00040.html
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org
:
bug#43173
; Package
guix-patches
.
(Wed, 02 Sep 2020 18:32:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 43173 <at> debbugs.gnu.org (full text, mbox):
* gnu/packages/linux.scm (linux-libre-deblob-scripts): Use VERSION instead of
VERSION-MAJOR+MINOR.
---
gnu/packages/linux.scm | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index b742688f79..8b66ed2b60 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -193,7 +193,7 @@ defconfig. Return the appropriate make target if applicable, otherwise return
(method url-fetch)
(uri (string-append "https://linux-libre.fsfla.org"
"/pub/linux-libre/releases/" version "-gnu/"
- "deblob-" (version-major+minor version)))
+ "deblob-" version))
(file-name (string-append "linux-libre-deblob-"
(version-major+minor version)))
(sha256 deblob-hash))
@@ -202,8 +202,7 @@ defconfig. Return the appropriate make target if applicable, otherwise return
(uri (string-append "https://linux-libre.fsfla.org"
"/pub/linux-libre/releases/" version "-gnu/"
"deblob-check"))
- (file-name (string-append "linux-libre-deblob-check-"
- (version-major+minor version)))
+ (file-name (string-append "linux-libre-deblob-check-" version))
(sha256 deblob-check-hash))))
(define deblob-scripts-5.8
--
2.28.0
Information forwarded
to
guix-patches <at> gnu.org
:
bug#43173
; Package
guix-patches
.
(Wed, 02 Sep 2020 18:32:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 43173 <at> debbugs.gnu.org (full text, mbox):
* gnu/packages/linux.scm (deblob-scripts-5.8, deblob-scripts-5.4,
deblob-scripts-4.19, deblob-scripts-4.14, deblob-scripts-4.9,
deblob-scripts-4.4): Use the respective LINUX-LIBRE-N-VERSION variables.
---
gnu/packages/linux.scm | 33 +++++++++++++++++++++------------
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 8b66ed2b60..727f3e07cc 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -180,6 +180,21 @@ defconfig. Return the appropriate make target if applicable, otherwise return
((string-prefix? "powerpc64le-" system) "ppc64_defconfig")
(else "defconfig")))
+
+;;;
+;;; Kernel versions.
+;;;
+
+;; The current "stable" kernel
+(define-public linux-libre-5.8-version "5.8.5")
+
+;; The "longterm" kernels with long-term upstream support
+(define-public linux-libre-5.4-version "5.4.61")
+(define-public linux-libre-4.19-version "4.19.142")
+(define-public linux-libre-4.14-version "4.14.195")
+(define-public linux-libre-4.9-version "4.9.234")
+(define-public linux-libre-4.4-version "4.4.234")
+
;;;
;;; Kernel source code deblobbing.
@@ -207,37 +222,37 @@ defconfig. Return the appropriate make target if applicable, otherwise return
(define deblob-scripts-5.8
(linux-libre-deblob-scripts
- "5.8.4"
+ linux-libre-5.8-version
(base32 "07z7sglyrfh0706icqqf3shadf638pvyid9386r661ds5lbsa2mw")
(base32 "0j6jba5fcddqlb42f95gjl78jisfla4nswqila074gglcrbnl9q7")))
(define deblob-scripts-5.4
(linux-libre-deblob-scripts
- "5.4.61"
+ linux-libre-5.4-version
(base32 "0ckxn7k5zgcqk30dq943bnamr6a6zjbw2aqjl3x30f4kvh5f6k25")
(base32 "1b3q88i2qfdxyvpi9f7jds0qlb8hfpw87mgia096ax6822c2cmyb")))
(define deblob-scripts-4.19
(linux-libre-deblob-scripts
- "4.19.142"
+ linux-libre-4.19-version
(base32 "02zs405awaxydbapka4nz8h6lmnc0dahgczqsrs5s2bmzjyyqkcy")
(base32 "1jiaw0as1ippkrjdpd52657w5mz9qczg3y2hlra7m9k0xawwiqlf")))
(define deblob-scripts-4.14
(linux-libre-deblob-scripts
- "4.14.195"
+ linux-libre-4.14-version
(base32 "091jk9jkn9jf39bxpc7395bhcb7p96nkg3a8047380ki06lnfxh6")
(base32 "1qij18inijj6c3ma8hv98yjagnzxdxyn134da9fd23ky8q6hbvky")))
(define deblob-scripts-4.9
(linux-libre-deblob-scripts
- "4.9.234"
+ linux-libre-4.9-version
(base32 "1wvldzlv7q2xdbadas87dh593nxr4a8p5n0f8zpm72lja6w18hmg")
(base32 "0fxajshb75siq39lj5h8xvhdj8lcmddkslwlyj65rhlwk6g2r4b2")))
(define deblob-scripts-4.4
(linux-libre-deblob-scripts
- "4.4.234"
+ linux-libre-4.4-version
(base32 "0x2j1i88am54ih2mk7gyl79g25l9zz4r08xhl482l3fvjj2irwbw")
(base32 "0hhin1jpfkd6nwrb6xqxjzl3hdxy4pn8a15hy2d3d83yw6pflbsf")))
@@ -382,7 +397,6 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
(sha256 hash)))
-(define-public linux-libre-5.8-version "5.8.5")
(define-public linux-libre-5.8-pristine-source
(let ((version linux-libre-5.8-version)
(hash (base32 "0zwl0nk3x6fxwsbnmpx1drh7v0116yhgamisb1pghd472mmw6klx")))
@@ -390,7 +404,6 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
(%upstream-linux-source version hash)
deblob-scripts-5.8)))
-(define-public linux-libre-5.4-version "5.4.61")
(define-public linux-libre-5.4-pristine-source
(let ((version linux-libre-5.4-version)
(hash (base32 "197y2yb60m1k8i7mig4pa9wsrklfxq81ba3zfahwb2b31w2kvwc6")))
@@ -398,7 +411,6 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
(%upstream-linux-source version hash)
deblob-scripts-5.4)))
-(define-public linux-libre-4.19-version "4.19.142")
(define-public linux-libre-4.19-pristine-source
(let ((version linux-libre-4.19-version)
(hash (base32 "19372sri4962dqf5rbr211lrfpckmj11kxsginfcwwid4hfdn4k9")))
@@ -406,7 +418,6 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
(%upstream-linux-source version hash)
deblob-scripts-4.19)))
-(define-public linux-libre-4.14-version "4.14.195")
(define-public linux-libre-4.14-pristine-source
(let ((version linux-libre-4.14-version)
(hash (base32 "08d08la3h48fbdlr3h8zbvdghydx3x9cwb4yrnm0n93hhrwjhkrr")))
@@ -414,7 +425,6 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
(%upstream-linux-source version hash)
deblob-scripts-4.14)))
-(define-public linux-libre-4.9-version "4.9.234")
(define-public linux-libre-4.9-pristine-source
(let ((version linux-libre-4.9-version)
(hash (base32 "1qw26x2qc29yr094c7scw68m9yz4j0b2c4f92rvi3s31s928avvm")))
@@ -422,7 +432,6 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
(%upstream-linux-source version hash)
deblob-scripts-4.9)))
-(define-public linux-libre-4.4-version "4.4.234")
(define-public linux-libre-4.4-pristine-source
(let ((version linux-libre-4.4-version)
(hash (base32 "123354h05fip161rzlxc8h0cn5lh0d1gz06gc5b7zyz9i2lxv539")))
--
2.28.0
Information forwarded
to
guix-patches <at> gnu.org
:
bug#43173
; Package
guix-patches
.
(Wed, 02 Sep 2020 21:10:01 GMT)
Full text and
rfc822 format available.
Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):
Leo Famulari <leo <at> famulari.name> writes:
> In recent discussions [0], people raised the possibility that we might
> accidentally leave non-free firmware blobs in our linux-libre packages.
>
> If I understand correctly, the root of the issue is that, currently, we
> manually specify the versions of the deblobbing scripts. They are not
> changed with every linux-libre release, so it is usually okay to use an
> older version number — the scripts themselves will be identical.
> However, sometimes the scripts do change, and we might not notice, and
> thus we would fail to remove every blob from the kernel sources.
>
> These two patches should make that failure mode impossible, by 1) making
> sure that the file names of the deblobbing scripts' store items include
> the full version number of the kernel and 2) only defining the version
> in one place. The hashes of the deblob scripts will be checked
> automatically when Guix downloads them for each new kernel release.
[...]
> [0] https://lists.gnu.org/archive/html/guix-devel/2020-08/msg00040.html
In the aforementioned discussion, I agreed to either:
(1) Wait until the linux-libre project publishes a new release, or
(2) Check for new blobs myself in the upstream release.
Since then, I've actually chosen option (2) a couple of times. I did so
by reviewing each of the upstream commits looking for new blobs.
I found that it took on the order of 10-15 minutes per release.
With this proposed change, we will lose an easy way to exercise option
(2), and will effectively be constrained to always wait until
linux-libre produces a new release.
I'll leave it to the maintainers to decide what to do here, but I wanted
to make it clear what's at stake. Personally, I do not find Jason and
Alexandre's arguments compelling, and would be in favor of retaining the
option to push these security updates more quickly by checking for new
blobs manually.
Thanks,
Mark
Information forwarded
to
guix-patches <at> gnu.org
:
bug#43173
; Package
guix-patches
.
(Wed, 02 Sep 2020 22:17:02 GMT)
Full text and
rfc822 format available.
Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Sep 02, 2020 at 05:07:56PM -0400, Mark H Weaver wrote:
> In the aforementioned discussion, I agreed to either:
>
> (1) Wait until the linux-libre project publishes a new release, or
> (2) Check for new blobs myself in the upstream release.
>
> Since then, I've actually chosen option (2) a couple of times. I did so
> by reviewing each of the upstream commits looking for new blobs.
> I found that it took on the order of 10-15 minutes per release.
>
> With this proposed change, we will lose an easy way to exercise option
> (2), and will effectively be constrained to always wait until
> linux-libre produces a new release.
We would still be able to use that method, by effectively reverting this
patch, as desired. The intended effect of this patch is that it will not
be possible to accidentally use the incorrect deblob scripts.
I think we should try to make it harder to make mistakes, but not forget
that we can remove the guardrails when we want to.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org
:
bug#43173
; Package
guix-patches
.
(Wed, 02 Sep 2020 23:55:02 GMT)
Full text and
rfc822 format available.
Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi Leo,
Leo Famulari <leo <at> famulari.name> writes:
> We would still be able to use that method, by effectively reverting this
> patch, as desired.
I suppose that's true. Fair enough :)
> The intended effect of this patch is that it will not be possible to
> accidentally use the incorrect deblob scripts.
I agree that it would be good to prevent this.
> I think we should try to make it harder to make mistakes, but not forget
> that we can remove the guardrails when we want to.
That makes sense. I withdraw my objection to the overall approach, but
I have a suggestion regarding the file organization:
Instead of having all 'linux-libre-*-version' definitions in one
section, all 'deblob-scripts-*' definitions in a second section, and all
'linux-libre-*-pristine-source' definitions in a third, I suggest
putting, for each kernel version, all three of these definitions
together in one place. That way, when performing the most common kernel
updates, everything that needs to be changed is in one place, and the
corresponding patch to Guix would have just one hunk.
More concretely, this would mean moving each 'deblob-scripts-X.Y'
definition down, between the corresponding 'linux-libre-X.Y-version' and
'linux-libre-X.Y-pristine-source' definitions.
What do you think?
Mark
Information forwarded
to
guix-patches <at> gnu.org
:
bug#43173
; Package
guix-patches
.
(Sat, 05 Sep 2020 19:05:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 43173 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Sep 02, 2020 at 07:53:02PM -0400, Mark H Weaver wrote:
> Instead of having all 'linux-libre-*-version' definitions in one
> section, all 'deblob-scripts-*' definitions in a second section, and all
> 'linux-libre-*-pristine-source' definitions in a third, I suggest
> putting, for each kernel version, all three of these definitions
> together in one place. That way, when performing the most common kernel
> updates, everything that needs to be changed is in one place, and the
> corresponding patch to Guix would have just one hunk.
>
> More concretely, this would mean moving each 'deblob-scripts-X.Y'
> definition down, between the corresponding 'linux-libre-X.Y-version' and
> 'linux-libre-X.Y-pristine-source' definitions.
>
> What do you think?
That's better than what I had in mind — thank you! I've attached a
revised patch.
[0001-gnu-linux-libre-Enforce-the-use-of-the-correct-deblo.patch (text/plain, attachment)]
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org
:
bug#43173
; Package
guix-patches
.
(Sat, 05 Sep 2020 23:09:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 43173 <at> debbugs.gnu.org (full text, mbox):
Leo Famulari <leo <at> famulari.name> writes:
> That's better than what I had in mind — thank you! I've attached a
> revised patch.
> From 6cbdf7e70ba0d9b98171a425bd249c702f8286de Mon Sep 17 00:00:00 2001
> From: Leo Famulari <leo <at> famulari.name>
> Date: Sat, 5 Sep 2020 14:46:04 -0400
> Subject: [PATCH] gnu: linux-libre: Enforce the use of the correct deblobbing
> scripts.
>
> * gnu/packages/linux.scm (deblob-scripts-5.8, deblob-scripts-5.4,
> deblob-scripts-4.19, deblob-scripts-4.14, deblob-scripts-4.9,
> deblob-scripts-4.4): Use the respective LINUX-LIBRE-X.Y-VERSION variables.
This new patch looks good to me. Feel free to push.
Thanks!
Mark
Reply sent
to
Leo Famulari <leo <at> famulari.name>
:
You have taken responsibility.
(Sun, 06 Sep 2020 20:02:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Leo Famulari <leo <at> famulari.name>
:
bug acknowledged by developer.
(Sun, 06 Sep 2020 20:02:01 GMT)
Full text and
rfc822 format available.
Message #31 received at 43173-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, Sep 05, 2020 at 07:07:01PM -0400, Mark H Weaver wrote:
> Leo Famulari <leo <at> famulari.name> writes:
>
> > That's better than what I had in mind — thank you! I've attached a
> > revised patch.
> > From 6cbdf7e70ba0d9b98171a425bd249c702f8286de Mon Sep 17 00:00:00 2001
> > From: Leo Famulari <leo <at> famulari.name>
> > Date: Sat, 5 Sep 2020 14:46:04 -0400
> > Subject: [PATCH] gnu: linux-libre: Enforce the use of the correct deblobbing
> > scripts.
> >
> > * gnu/packages/linux.scm (deblob-scripts-5.8, deblob-scripts-5.4,
> > deblob-scripts-4.19, deblob-scripts-4.14, deblob-scripts-4.9,
> > deblob-scripts-4.4): Use the respective LINUX-LIBRE-X.Y-VERSION variables.
>
> This new patch looks good to me. Feel free to push.
Thanks for your review! Pushed as fe752d8c4545735edd71362805cbe78b78b8e9ab
[signature.asc (application/pgp-signature, inline)]
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 05 Oct 2020 11:24:07 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 314 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.