linux-libre: compare guix-generated sources against upstream releases

  • Done
  • quality assurance status badge
Details
4 participants
  • Maxim Cournoyer
  • Mark H Weaver
  • Mike Rosset
  • Mathieu Othacehe
Owner
unassigned
Submitted by
Maxim Cournoyer
Severity
normal
M
M
Maxim Cournoyer wrote on 1 Sep 2020 22:38
[PATCH] gnu: linux-libre: Use Python 3 in make-linux-libre-source.
(address . guix-patches@gnu.org)(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
20200901203859.4695-1-maxim.cournoyer@gmail.com
Successfully tested with all of the linux-libre versions we carry in Guix:
4.4.234, 4.9.234, 4.14.195, 4.19.142, 5.4.61 and 5.8.5.

* gnu/packages/linux.scm (make-linux-libre-source): Replace python-2 by
python-wrapper.
---
gnu/packages/linux.scm | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)

Toggle diff (19 lines)
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index d3365e7a4b..e9bfca25af 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -296,11 +296,7 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
#+(canonical-package bzip2)
#+(canonical-package gzip)
#+(canonical-package tar)
- ;; The comments in the 'deblob-check' script
- ;; claim that it supports Python 2 and 3, but
- ;; in fact it fails when run in Python 3 as
- ;; of version 5.1.3.
- #+python-2))
+ #+python-wrapper))
(with-directory-excursion "/tmp/bin"
--
2.27.0
M
M
Maxim Cournoyer wrote on 1 Sep 2020 22:41
[PATCH 1/2] gnu: make-linux-libre-source: Set output port buffering to line mode.
(address . 43160@debbugs.gnu.org)(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
20200901204152.4802-1-maxim.cournoyer@gmail.com
* gnu/packages/linux.scm (make-linux-libre-source): Set output port buffering
to line mode via setvbuf. Remove the ad-hoc calls to force-output.
---
gnu/packages/linux.scm | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)

Toggle diff (41 lines)
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index e9bfca25af..9507178fb6 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -279,6 +279,9 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
(srfi srfi-1)
(ice-9 match)
(ice-9 ftw))
+
+ (setvbuf (current-output-port) 'line)
+
(let ((dir (string-append "linux-" #$version)))
(mkdir "/tmp/bin")
@@ -315,12 +318,10 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
(if (file-is-directory? #+upstream-source)
(begin
(format #t "Copying upstream linux source...~%")
- (force-output)
(invoke "cp" "--archive" #+upstream-source dir)
(invoke "chmod" "--recursive" "u+w" dir))
(begin
(format #t "Unpacking upstream linux tarball...~%")
- (force-output)
(invoke "tar" "xf" #$upstream-source)
(match (scandir "."
(lambda (name)
@@ -335,11 +336,9 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
(with-directory-excursion dir
(setenv "PYTHON" (which "python"))
(format #t "Running deblob script...~%")
- (force-output)
(invoke "/tmp/bin/deblob"))
(format #t "~%Packing new Linux-libre tarball...~%")
- (force-output)
(invoke "tar" "cvfa" #$output
;; Avoid non-determinism in the archive.
"--mtime=@0"
--
2.27.0
M
M
Maxim Cournoyer wrote on 1 Sep 2020 22:41
[PATCH 2/2] gnu: linux-libre: Validate that the cleaned up tarball is free of blobs.
(address . 43160@debbugs.gnu.org)(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
20200901204152.4802-2-maxim.cournoyer@gmail.com
* gnu/packages/linux.scm (make-linux-libre-source): Call the deblob-check
script on the generated tarball archive with the --use-awk and --list-blobs
options.
---
gnu/packages/linux.scm | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)

Toggle diff (35 lines)
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 9507178fb6..cd9c3a18fa 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -48,6 +48,7 @@
;;; Copyright © 2020 John Soo <jsoo1@asu.edu>
;;; Copyright © 2020 Michael Rohleder <mike@rohleder.de>
;;; Copyright © 2020 Anders Thuné <asse.97@gmail.com>
+;;; Copyright © 2020 Maxim Cournoyer <maxim.cournoyer@gmail.com>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -90,6 +91,7 @@
#:use-module (gnu packages flex)
#:use-module (gnu packages file)
#:use-module (gnu packages freedesktop)
+ #:use-module (gnu packages gawk)
#:use-module (gnu packages gcc)
#:use-module (gnu packages gettext)
#:use-module (gnu packages glib)
@@ -346,7 +348,11 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
"--group=root:0"
"--sort=name"
"--hard-dereference"
- dir))))))))))
+ dir)
+
+ (format #t "~%Validating the generated tarball...~%")
+ (invoke "/tmp/bin/deblob-check" "--use-awk" "--list-blobs"
+ #$output))))))))))
;;;
--
2.27.0
M
M
Maxim Cournoyer wrote on 2 Sep 2020 14:56
[PATCH v2 1/4] gnu: linux-libre: Use Python 3 in make-linux-libre-source.
(address . 43160@debbugs.gnu.org)(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
20200902125643.27201-1-maxim.cournoyer@gmail.com
Successfully tested with all of the linux-libre versions we carry in Guix:
4.4.234, 4.9.234, 4.14.195, 4.19.142, 5.4.61 and 5.8.5.

* gnu/packages/linux.scm (make-linux-libre-source): Replace python-2 by
python-wrapper. Do not set the PYTHON environment variable, which is not
required when using python-wrapper.
---
gnu/packages/linux.scm | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)

Toggle diff (27 lines)
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index d3b3f4de9c..8edbe4e7e4 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -296,11 +296,7 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
#+(canonical-package bzip2)
#+(canonical-package gzip)
#+(canonical-package tar)
- ;; The comments in the 'deblob-check' script
- ;; claim that it supports Python 2 and 3, but
- ;; in fact it fails when run in Python 3 as
- ;; of version 5.1.3.
- #+python-2))
+ #+python-wrapper))
(with-directory-excursion "/tmp/bin"
@@ -337,7 +333,6 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
(error "multiple directories found" dirs)))))
(with-directory-excursion dir
- (setenv "PYTHON" (which "python"))
(format #t "Running deblob script...~%")
(force-output)
(invoke "/tmp/bin/deblob"))
--
2.27.0
M
M
Maxim Cournoyer wrote on 2 Sep 2020 14:56
[PATCH v2 2/4] gnu: make-linux-libre-source: Set output port buffering to line mode.
(address . 43160@debbugs.gnu.org)(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
20200902125643.27201-2-maxim.cournoyer@gmail.com
* gnu/packages/linux.scm (make-linux-libre-source): Set output port buffering
to line mode via setvbuf. Remove the ad-hoc calls to force-output.
---
gnu/packages/linux.scm | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)

Toggle diff (41 lines)
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 8edbe4e7e4..1b923f0c0a 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -279,6 +279,9 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
(srfi srfi-1)
(ice-9 match)
(ice-9 ftw))
+
+ (setvbuf (current-output-port) 'line)
+
(let ((dir (string-append "linux-" #$version)))
(mkdir "/tmp/bin")
@@ -315,12 +318,10 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
(if (file-is-directory? #+upstream-source)
(begin
(format #t "Copying upstream linux source...~%")
- (force-output)
(invoke "cp" "--archive" #+upstream-source dir)
(invoke "chmod" "--recursive" "u+w" dir))
(begin
(format #t "Unpacking upstream linux tarball...~%")
- (force-output)
(invoke "tar" "xf" #$upstream-source)
(match (scandir "."
(lambda (name)
@@ -334,11 +335,9 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
(with-directory-excursion dir
(format #t "Running deblob script...~%")
- (force-output)
(invoke "/tmp/bin/deblob"))
(format #t "~%Packing new Linux-libre tarball...~%")
- (force-output)
(invoke "tar" "cvfa" #$output
;; Avoid non-determinism in the archive.
"--mtime=@0"
--
2.27.0
M
M
Maxim Cournoyer wrote on 2 Sep 2020 14:56
[PATCH v2 3/4] gnu: linux-libre: Validate that the cleaned up tarball is free of blobs.
(address . 43160@debbugs.gnu.org)(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
20200902125643.27201-3-maxim.cournoyer@gmail.com
* gnu/packages/linux.scm (make-linux-libre-source): Call the deblob-check
script on the generated tarball archive with the --use-awk and --list-blobs
options.
---
gnu/packages/linux.scm | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)

Toggle diff (43 lines)
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 1b923f0c0a..e177386312 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -48,6 +48,7 @@
;;; Copyright © 2020 John Soo <jsoo1@asu.edu>
;;; Copyright © 2020 Michael Rohleder <mike@rohleder.de>
;;; Copyright © 2020 Anders Thuné <asse.97@gmail.com>
+;;; Copyright © 2020 Maxim Cournoyer <maxim.cournoyer@gmail.com>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -90,6 +91,7 @@
#:use-module (gnu packages flex)
#:use-module (gnu packages file)
#:use-module (gnu packages freedesktop)
+ #:use-module (gnu packages gawk)
#:use-module (gnu packages gcc)
#:use-module (gnu packages gettext)
#:use-module (gnu packages glib)
@@ -299,6 +301,7 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
#+(canonical-package bzip2)
#+(canonical-package gzip)
#+(canonical-package tar)
+ #+(canonical-package gawk)
#+python-wrapper))
(with-directory-excursion "/tmp/bin"
@@ -345,7 +348,11 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
"--group=root:0"
"--sort=name"
"--hard-dereference"
- dir))))))))))
+ dir)
+
+ (format #t "~%Scanning the generated tarball for blobs...~%")
+ (invoke "/tmp/bin/deblob-check" "--use-awk" "--list-blobs"
+ #$output))))))))))
;;;
--
2.27.0
M
M
Maxim Cournoyer wrote on 2 Sep 2020 14:56
[PATCH v2 4/4] gnu: linux-libre: Compare generated sources against Linux-libre releases.
(address . 43160@debbugs.gnu.org)(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
20200902125643.27201-4-maxim.cournoyer@gmail.com
* gnu/packages/linux.scm (make-linux-libre-source): Rename the UPSTREAM-SOURCE
parameter to LINUX-UPSTREAM-SOURCE. Add a new LINUX-LIBRE-UPSTREAM-SOURCE
parameter. Update doc. Adjust variable names. Capitalize "Linux" in the
user messages. Remove empty directories from the generated sources, then
invoke diff between these sources and those of the corresponding Linux-libre
release.
(%upstream-linux-source): Convert the hash as base32 inside the definition, to
simplify its use.
(%upstream-linux-libre-source): New procedure.
(linux-libre-5.8-pristine-source): Add a LIBRE-HASH binding and use it with
%UPSTREAM-LINUX-LIBRE-SOURCE to provide the Linux-libre release origin to the
make-linux-libre-source procedure call.
(linux-libre-5.4-pristine-source): Likewise.
(linux-libre-4.19-pristine-source): Likewise.
(linux-libre-4.14-pristine-source): Likewise.
(linux-libre-4.9-pristine-source): Likewise.
(linux-libre-4.4-pristine-source): Likewise.
---
gnu/packages/linux.scm | 63 ++++++++++++++++++++++++++++++++----------
1 file changed, 48 insertions(+), 15 deletions(-)

Toggle diff (144 lines)
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index e177386312..020eb1670c 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -258,10 +258,14 @@ from forcing GEXP-PROMISE."
#:guile-for-build guile)))
(define (make-linux-libre-source version
- upstream-source
+ linux-upstream-source
+ linux-libre-upstream-source
deblob-scripts)
"Return a 'computed' origin that generates a Linux-libre tarball from the
-corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
+corresponding LINUX-UPSTREAM-SOURCE (an origin), using the given
+DEBLOB-SCRIPTS. The generated Linux-libre source is compared against the
+corresponding LINUX-LIBRE-UPSTREAM-SOURCE upstream release (an origin), to
+ensure correctness."
(match deblob-scripts
((deblob-version (? origin? deblob) (? origin? deblob-check))
(unless (string=? deblob-version (version-major+minor version))
@@ -318,14 +322,14 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
(("/bin/sed") (which "sed"))
(("/usr/bin/python") (which "python"))))
- (if (file-is-directory? #+upstream-source)
+ (if (file-is-directory? #+linux-upstream-source)
(begin
- (format #t "Copying upstream linux source...~%")
- (invoke "cp" "--archive" #+upstream-source dir)
+ (format #t "Copying upstream Linux source...~%")
+ (invoke "cp" "--archive" #+linux-upstream-source dir)
(invoke "chmod" "--recursive" "u+w" dir))
(begin
- (format #t "Unpacking upstream linux tarball...~%")
- (invoke "tar" "xf" #$upstream-source)
+ (format #t "Unpacking upstream Linux tarball...~%")
+ (invoke "tar" "xf" #$linux-upstream-source)
(match (scandir "."
(lambda (name)
(and (not (member name '("." "..")))
@@ -352,7 +356,16 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
(format #t "~%Scanning the generated tarball for blobs...~%")
(invoke "/tmp/bin/deblob-check" "--use-awk" "--list-blobs"
- #$output))))))))))
+ #$output)
+
+ (format #t "~%Comparing with the upstream Linux-libre \
+release...~%")
+ ;; Git doesn't track empty directories, so remove them from
+ ;; our local tree for the sake of comparison.
+ (invoke "find" dir "-type" "d" "-empty" "-delete")
+ (invoke "diff" "-ur"
+ dir
+ #+linux-libre-upstream-source))))))))))
;;;
@@ -381,55 +394,75 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
(uri (string-append "mirror://kernel.org"
"/linux/kernel/v" (version-major version) ".x/"
"linux-" version ".tar.xz"))
- (sha256 hash)))
+ (sha256 (base32 hash))))
+(define (%upstream-linux-libre-source version hash)
+ (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "git://linux-libre.fsfla.org/releases.git")
+ (commit (string-append "sources/v" version "-gnu"))))
+ (file-name (git-file-name "linux-libre-source" version))
+ (sha256 (base32 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")))
+ (hash "0zwl0nk3x6fxwsbnmpx1drh7v0116yhgamisb1pghd472mmw6klx")
+ (libre-hash "0blgkbfvl5p6y6fj0xkdnd0dk2qla02pc37gj7dc3ha0asxv4mp8"))
(make-linux-libre-source version
(%upstream-linux-source version hash)
+ (%upstream-linux-libre-source version libre-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")))
+ (hash "197y2yb60m1k8i7mig4pa9wsrklfxq81ba3zfahwb2b31w2kvwc6")
+ (libre-hash "1ycbalnlmgbaq3yh7yc7l8gw7c8d2x4jbwildf04zgfq9g0lv78m"))
(make-linux-libre-source version
(%upstream-linux-source version hash)
+ (%upstream-linux-libre-source version libre-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")))
+ (hash "19372sri4962dqf5rbr211lrfpckmj11kxsginfcwwid4hfdn4k9")
+ (libre-hash "1281d0rx17yiy9723ig381jq3bww59xqggisbxhdrxvfbxv0vvp4"))
(make-linux-libre-source version
(%upstream-linux-source version hash)
+ (%upstream-linux-libre-source version libre-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")))
+ (hash "08d08la3h48fbdlr3h8zbvdghydx3x9cwb4yrnm0n93hhrwjhkrr")
+ (libre-hash "0vgfw8jv3mnn6d9pvccqvx4v143ck02inivnhmxylq0nqfxb7nj4"))
(make-linux-libre-source version
(%upstream-linux-source version hash)
+ (%upstream-linux-libre-source version libre-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")))
+ (hash "1qw26x2qc29yr094c7scw68m9yz4j0b2c4f92rvi3s31s928avvm")
+ (libre-hash "1p7dpsqad9vra22r00ha6vg2fap4jjplfkcaskz9fvih6m4m7wgp"))
(make-linux-libre-source version
(%upstream-linux-source version hash)
+ (%upstream-linux-libre-source version libre-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")))
+ (hash "123354h05fip161rzlxc8h0cn5lh0d1gz06gc5b7zyz9i2lxv539")
+ (libre-hash "07adliis6kln7531jwwl0h2v9wkzn2j3jn2zjlyashxd9p85kywm"))
(make-linux-libre-source version
(%upstream-linux-source version hash)
+ (%upstream-linux-libre-source version libre-hash)
deblob-scripts-4.4)))
(define %boot-logo-patch
--
2.27.0
M
M
Mathieu Othacehe wrote on 3 Sep 2020 07:50
Re: [bug#43160] [PATCH v2 1/4] gnu: linux-libre: Use Python 3 in make-linux-libre-source.
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . 43160@debbugs.gnu.org)
87o8mne7ct.fsf@gnu.org
Hello Maxim,

Toggle quote (3 lines)
> Successfully tested with all of the linux-libre versions we carry in Guix:
> 4.4.234, 4.9.234, 4.14.195, 4.19.142, 5.4.61 and 5.8.5.

This looks fine. Did you check if cross-compilation is also working
correctly?

Thanks,

Mathieu
M
M
Maxim Cournoyer wrote on 3 Sep 2020 15:08
(name . Mathieu Othacehe)(address . othacehe@gnu.org)(address . 43160@debbugs.gnu.org)
874koff1o1.fsf@gmail.com
Hello Mathieu,

Mathieu Othacehe <othacehe@gnu.org> writes:

Toggle quote (8 lines)
> Hello Maxim,
>
>> Successfully tested with all of the linux-libre versions we carry in Guix:
>> 4.4.234, 4.9.234, 4.14.195, 4.19.142, 5.4.61 and 5.8.5.
>
> This looks fine. Did you check if cross-compilation is also working
> correctly?

I just tested with guix build --system=linux-armhf --check --source, and
it seems to be working correctly. I pushed that single commit to master
as f029bca1032c7e032f2920540b0aa1a3733e2cc9.

Thank you,

Maxim
M
M
Mathieu Othacehe wrote on 4 Sep 2020 08:15
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . 43160@debbugs.gnu.org)
87tuweqd8x.fsf@gnu.org
Hey Maxim,

Toggle quote (4 lines)
> I just tested with guix build --system=linux-armhf --check --source, and
> it seems to be working correctly. I pushed that single commit to master
> as f029bca1032c7e032f2920540b0aa1a3733e2cc9.

Great. I just had a look to the rest of the patchset. This seems fine to
me :).

Thanks,

Mathieu
M
M
Mike Rosset wrote on 4 Sep 2020 16:45
(name . Mathieu Othacehe)(address . othacehe@gnu.org)
87zh65iorf.fsf@gmail.com
Mathieu Othacehe <othacehe@gnu.org> writes:

Toggle quote (7 lines)
> Great. I just had a look to the rest of the patchset. This seems fine to
> me :).
>
> Thanks,
>
> Mathieu

Hello Mathieu

Thanks for looking at this. I have split the patch into 3 commits and
emailed as a new series.

Mike
M
M
Mark H Weaver wrote on 4 Sep 2020 17:21
Re: Validate the result of our linux-libre sources clean up
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
874kodsh21.fsf@netris.org
Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
Toggle quote (4 lines)
> I'd like to point you to the following patches, as they touch the
> generation of the linux-libre sources, in case they hadn't caught your
> attention: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43160.

Thanks very much for bringing this to my attention. I do not subscribe
to the guix-patches list, so I would not have seen this otherwise.

I'm in favor of the following patches:

gnu: linux-libre: Use Python 3 in make-linux-libre-source.
gnu: make-linux-libre-source: Set output port buffering to line mode.
gnu: linux-libre: Validate that the cleaned up tarball is free of blobs.

Thanks for these. Please push them whenever you feel is appropriate.

On other other hand, I'm strongly opposed to the following patch:

gnu: linux-libre: Compare generated sources against Linux-libre releases.

I'm opposed to it because it would make it prohibitively difficult to
push micro kernel updates (most of which contain potential security
fixes) before Linux-libre has published their tarball release. It would
also make it prohibitively difficult to perform deblobbed bisections
between two adjacent versions from the upstream stable git repository.

In my opinion, at minimum, the 'linux-libre-upstream-source' argument to
'make-linux-libre-source' should optional.

I find it depressing that Jason's and Alexandre's attempts to browbeat
us to limit ourselves to deblob only the precise tarballs that they
produce, and to always wait for them to produce them before pushing
security fixes (although it takes less than 10 minutes to look over the
upstream commits for new blobs) have gained traction here.

Thanks,
Mark
M
M
Maxim Cournoyer wrote on 5 Sep 2020 03:51
Re: [bug#43160] [PATCH v2 1/4] gnu: linux-libre: Use Python 3 in make-linux-libre-source.
(name . Mathieu Othacehe)(address . othacehe@gnu.org)(address . 43160@debbugs.gnu.org)
87d031dm8y.fsf@gmail.com
Hello!

Mathieu Othacehe <othacehe@gnu.org> writes:

Toggle quote (9 lines)
> Hey Maxim,
>
>> I just tested with guix build --system=linux-armhf --check --source, and
>> it seems to be working correctly. I pushed that single commit to master
>> as f029bca1032c7e032f2920540b0aa1a3733e2cc9.
>
> Great. I just had a look to the rest of the patchset. This seems fine to
> me :).

Thank you! As you and Mark agreed that the first 3 were good to go, I've
now pushed them. The last one is still in discussion with Mark.

Thanks,

Maxim
M
M
Maxim Cournoyer wrote on 7 Sep 2020 21:25
Re: [bug#43160] Validate the result of our linux-libre sources clean up
(name . Mark H Weaver)(address . mhw@netris.org)
87imcpbd8d.fsf@gmail.com
Hi Mark!

Mark H Weaver <mhw@netris.org> writes:

Toggle quote (18 lines)
> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>> I'd like to point you to the following patches, as they touch the
>> generation of the linux-libre sources, in case they hadn't caught your
>> attention: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43160.
>
> Thanks very much for bringing this to my attention. I do not subscribe
> to the guix-patches list, so I would not have seen this otherwise.
>
> I'm in favor of the following patches:
>
> gnu: linux-libre: Use Python 3 in make-linux-libre-source.
> gnu: make-linux-libre-source: Set output port buffering to line mode.
> gnu: linux-libre: Validate that the cleaned up tarball is free of blobs.
>
> Thanks for these. Please push them whenever you feel is appropriate.

Thanks for taking a look! I've now done so.

Toggle quote (8 lines)
> On other other hand, I'm strongly opposed to the following patch:
>
> gnu: linux-libre: Compare generated sources against Linux-libre releases.
>
> I'm opposed to it because it would make it prohibitively difficult to
> push micro kernel updates (most of which contain potential security
> fixes) before Linux-libre has published their tarball release.

Following recent discussions, I had understood that you agreed to wait
for the Linux-libre releases before bumping our own releases. It seems
the Linux-libre releases occur fast enough to not pose much of a
security issue; below is what I did to arrive to this conclusion.

For Linux stable, the author dates of the last releases of the version 5
series, omitting release candidates:

Toggle snippet (25 lines)
$ git tag | grep -E '5\.[0-9]+\.' | grep -v -- '-rc' \
| sort -t '.' -k1,1n -k2,2n -k3,3n | tail -n20 \
| xargs -i{} git log --date='format:%c' --pretty='%ad %d' {} -1
Wed 24 Jun 2020 05:49:26 PM GMT (tag: v5.7.6)
Tue 30 Jun 2020 04:21:22 PM GMT (tag: v5.7.7)
Thu 09 Jul 2020 09:39:40 AM GMT (tag: v5.7.8)
Thu 16 Jul 2020 08:13:36 AM GMT (tag: v5.7.9)
Wed 22 Jul 2020 09:34:29 AM GMT (tag: v5.7.10)
Wed 29 Jul 2020 10:20:01 AM GMT (tag: v5.7.11)
Fri 31 Jul 2020 06:47:17 PM GMT (tag: v5.7.12)
Wed 05 Aug 2020 09:58:51 AM GMT (tag: v5.7.13)
Fri 07 Aug 2020 09:33:11 AM GMT (tag: v5.7.14)
Tue 11 Aug 2020 03:35:42 PM GMT (tag: v5.7.15)
Wed 19 Aug 2020 08:24:20 AM GMT (tag: v5.7.16)
Fri 21 Aug 2020 01:07:46 PM GMT (tag: v5.7.17)
Wed 26 Aug 2020 11:42:25 AM GMT (tag: v5.7.18)
Thu 27 Aug 2020 09:30:50 AM GMT (tag: v5.7.19, origin/linux-5.7.y)
Tue 11 Aug 2020 03:48:12 PM GMT (tag: v5.8.1)
Wed 19 Aug 2020 08:27:10 AM GMT (tag: v5.8.2)
Fri 21 Aug 2020 01:15:22 PM GMT (tag: v5.8.3)
Wed 26 Aug 2020 11:49:20 AM GMT (tag: v5.8.4)
Thu 27 Aug 2020 09:31:49 AM GMT (tag: v5.8.5)
Thu 03 Sep 2020 11:29:52 AM GMT (tag: v5.8.6, origin/linux-5.8.y)

Similarly, for Linux-libre:

Toggle snippet (25 lines)
git tag | grep -E 'sources/v5\.[0-9]+\.' | grep -v -- '-rc' \
| sort -t '.' -k1,1n -k2,2n -k3,3n | tail -n20 \
| xargs -i{} git log --date='format:%c' --pretty='%ad %d' {} -1
Wed 24 Jun 2020 02:51:34 PM GMT (tag: sources/v5.7.6-gnu)
Wed 01 Jul 2020 02:01:47 PM GMT (tag: sources/v5.7.7-gnu)
Thu 09 Jul 2020 08:59:49 AM GMT (tag: sources/v5.7.8-gnu)
Thu 16 Jul 2020 11:51:43 AM GMT (tag: sources/v5.7.9-gnu)
Wed 22 Jul 2020 06:40:22 AM GMT (tag: sources/v5.7.10-gnu)
Wed 29 Jul 2020 06:33:25 AM GMT (tag: sources/v5.7.11-gnu)
Fri 31 Jul 2020 02:22:04 PM GMT (tag: sources/v5.7.12-gnu)
Wed 05 Aug 2020 05:44:37 AM GMT (tag: sources/v5.7.13-gnu)
Fri 07 Aug 2020 04:46:28 AM GMT (tag: sources/v5.7.14-gnu)
Tue 11 Aug 2020 02:48:28 PM GMT (tag: sources/v5.7.15-gnu)
Wed 19 Aug 2020 02:14:46 PM GMT (tag: sources/v5.7.16-gnu)
Fri 21 Aug 2020 09:37:45 AM GMT (tag: sources/v5.7.17-gnu)
Wed 26 Aug 2020 07:27:54 AM GMT (tag: sources/v5.7.18-gnu)
Thu 27 Aug 2020 01:14:21 PM GMT (tag: sources/v5.7.19-gnu)
Tue 11 Aug 2020 02:47:58 PM GMT (tag: sources/v5.8.1-gnu)
Wed 19 Aug 2020 02:15:42 PM GMT (tag: sources/v5.8.2-gnu)
Fri 21 Aug 2020 09:37:45 AM GMT (tag: sources/v5.8.3-gnu)
Wed 26 Aug 2020 07:27:54 AM GMT (tag: sources/v5.8.4-gnu)
Thu 27 Aug 2020 01:14:21 PM GMT (tag: sources/v5.8.5-gnu)
Thu 03 Sep 2020 07:14:30 AM GMT (tag: sources/v5.8.6-gnu)

While the author dates of the commits don't appear to be very precise
(some Linux-libre commits would have occurred before their Linux
counterpart), we can at least see that each Linux release was met with a
Linux-libre on the same day for all except the 5.7.7 release.

Also, if we compare with our own Linux-libre update timings:

Toggle snippet (24 lines)
git log --grep 'gnu: linux-libre: Update to 5' --date='format:%c' \
--pretty='%ad %s' | head -n20 | sort -r -t '.' -k1,1n -k2,2n -k3,3n
Thu 11 Jun 2020 04:15:35 PM GMT gnu: linux-libre: Update to 5.4.46.
Thu 18 Jun 2020 12:39:23 AM GMT gnu: linux-libre: Update to 5.4.47
Mon 22 Jun 2020 09:02:33 PM GMT gnu: linux-libre: Update to 5.4.48.
Wed 24 Jun 2020 09:08:00 PM GMT gnu: linux-libre: Update to 5.4.49.
Wed 01 Jul 2020 01:31:06 PM GMT gnu: linux-libre: Update to 5.4.50.
Thu 09 Jul 2020 04:40:27 PM GMT gnu: linux-libre: Update to 5.4.51.
Thu 16 Jul 2020 03:37:05 PM GMT gnu: linux-libre: Update to 5.4.52.
Thu 23 Jul 2020 12:28:46 AM GMT gnu: linux-libre: Update to 5.4.53.
Wed 29 Jul 2020 05:14:00 PM GMT gnu: linux-libre: Update to 5.4.54.
Sat 01 Aug 2020 12:07:08 AM GMT gnu: linux-libre: Update to 5.4.55.
Wed 05 Aug 2020 03:21:53 PM GMT gnu: linux-libre: Update to 5.4.56.
Sat 01 Aug 2020 12:39:30 PM GMT gnu: linux-libre: Update to 5.7.12.
Fri 07 Aug 2020 09:37:11 PM GMT gnu: linux-libre: Update to 5.7.14.
Tue 11 Aug 2020 05:34:48 PM GMT gnu: linux-libre: Update to 5.7.15.
Wed 19 Aug 2020 07:35:03 PM GMT gnu: linux-libre: Update to 5.7.16.
Thu 20 Aug 2020 04:03:46 PM GMT gnu: linux-libre: Update to 5.8.2.
Fri 21 Aug 2020 09:01:17 PM GMT gnu: linux-libre: Update to 5.8.3.
Wed 26 Aug 2020 04:01:11 PM GMT gnu: linux-libre: Update to 5.8.4.
Thu 27 Aug 2020 04:13:32 PM GMT gnu: linux-libre: Update to 5.8.5.
Thu 03 Sep 2020 01:56:31 PM GMT gnu: linux-libre: Update to 5.8.6.

For the subset that we did package, we were always trailing the
Linux-libre releases, so the argument that waiting for their releases
would hamper our security doesn't seem to hold.

Toggle quote (3 lines)
> also make it prohibitively difficult to perform deblobbed bisections
> between two adjacent versions from the upstream stable git repository.

In my opinion, we should not trade our correctness guarantee in exchange
for convenience, especially if the convenience is only gained in such a
corner case as per-commit bisection of the Linux kernel. It'd be
oversimplifying to say that the Linux-libre developers just run their
scripts to produce a release; they also manually screen the new upstream
changes and update their scripts accordingly. To give due credit to
their efforts, we should not simply run their scripts with a newer
version/commit of Linux and expect arriving at a correct result.

Toggle quote (3 lines)
> In my opinion, at minimum, the 'linux-libre-upstream-source' argument to
> 'make-linux-libre-source' should optional.

Perhaps, like for the change proposed by Leo, the edge case of bisecting
per-commit could be accommodated by reverting this patch when needed?
It seems more important that the common case be rigorously verified.

Also note that it should be possible to:

1) Test each packaged release in Guix to "bisect" (duh)
2) Test any Linux stable release via the Linux-libre git repo, building
with a command such as "guix build
--with-git-url=linux-libre=git://linux-libre.fsfla.org/releases.git
--with-commit=linux-libre=sources/v5.8.3-gnu linux-libre". Unfortunately
this can't be done from the command line using 'guix system build ...'
but it should be easy to define your own linux-libre package using the
'make-linux-libre*' procedure (which will gladly accept any linux-libre
source).

For when the per-commit granularity is not required.

In the future, the linux-libre git repo will apply their clean ups per
commit, allowing to do like 2) above for any commit.

Toggle quote (6 lines)
> I find it depressing that Jason's and Alexandre's attempts to browbeat
> us to limit ourselves to deblob only the precise tarballs that they
> produce, and to always wait for them to produce them before pushing
> security fixes (although it takes less than 10 minutes to look over the
> upstream commits for new blobs) have gained traction here.

Despite the somewhat corrosive tone of the exchange, some valid points
were made. I've scavenged these and adapted the recipe. I think the
end result is a win-win situation for both Linux-libre and Guix.

As shown above, there hasn't been a case where the Linux-libre effort
slowed down the deployment of a new Linux kernel version in Guix. I
don't foresee this changing.

What do you think? Are there holes in my analysis/understanding?

Thank you,

Maxim
M
M
Mark H Weaver wrote on 8 Sep 2020 01:38
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87a6y1cg3i.fsf@netris.org
Hi Maxim,

Thanks again for the patches that you've already pushed.
They are a great improvement.

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

Toggle quote (9 lines)
> Mark H Weaver <mhw@netris.org> writes:
>
>> I'm opposed to it because it would make it prohibitively difficult to
>> push micro kernel updates (most of which contain potential security
>> fixes) before Linux-libre has published their tarball release.
>
> Following recent discussions, I had understood that you agreed to wait
> for the Linux-libre releases before bumping our own releases.

Sorry, but that's incorrect. I agreed to either wait or to look for new
blobs myself. I've already exercised that second option a couple of
times since making that pledge. I've found it to be quite easy. The
overwhelming majority of commits to the stable branches are bug fixes
that obviously do not add anything resembling a blob.

If you haven't already done so, I'd encourage you to look over the
upstream commits between two consecutive upstream stable releases, to
see more concretely what I'm talking about, and how straightforward it
is to conclude that no new blobs could possibly have been added.

Toggle quote (3 lines)
> It seems the Linux-libre releases occur fast enough to not pose much
> of a security issue; below is what I did to arrive to this conclusion.

The timestamp data you collected is clearly off by several hours. It
appears to show that over two thirds of linux-libre releases come out
*before* the corresponding linux release. One third of them appear to
have come out more than 4 hours before the corresponding linux release.
That cannot be right. I guess someone's clock is off by several hours,
or somehow the timezones are not being taken into account.

I can tell you that within the last couple of weeks, since my pledge to
either wait for linux-libre or to check for blobs myself, I very clearly
remember upstream updates being tagged a few hours after midnight one
morning, and that it was not until after dark the next evening before
linux-libre had tagged their releases. That instance is not reflected
in the data you collected, which again suggests to me that there's a
very significant systemic error in that data.

Even with this apparently large bias in the data, it shows that
linux-libre-5.7.7 was tagged almost 22 hours after the corresponding
linux release. Most likely that was actually at least 28 hours.

Please don't misunderstand me: I do not fault the Linux-libre developers
for not being quick enough. On the contrary, they've been consistently
*excellent* in that regard for as long as I've been paying attention. I
certainly don't fault them for occasionally spending some time away from
their computers.

What I _do_ fault them for is *insisting* on placing themselves in the
middle of what should be a fast path for security updates from the
upstream developers to us.

To my mind, the practices that the Linux-libre developers are attempting
to impose on us feel like Service as a Software Substitute (SaaSS), but
in this case enforced by social pressure (and the suggestion that it
might violate the GNU FSDG) instead of the usual technical restrictions.

I'll also note that what you're proposing will apparently not be enough
to satisfy Jason and Alexandre. They've gone so far as to suggest that
it's improper for an FSDG-compliant distribution to ever download
non-FSDG-compliant source code to a user machine. It seems that to
satisfy them, Guix developers would apparently need to host our own
distribution site for cleaned-up copies of source tarballs, and to use
some separate tools to produce and upload new source tarballs to this
site for every update of software whose upstream source is not
FSDG-compliant.

I don't know about you, but I find their demands *oppressive*.

Toggle quote (6 lines)
>> also make it prohibitively difficult to perform deblobbed bisections
>> between two adjacent versions from the upstream stable git repository.
>
> In my opinion, we should not trade our correctness guarantee in exchange
> for convenience,

First, I think that it's a mistake to suggest that any "correctness
guarantee" exists or could exist in Guix, with or without your proposed
patch. Massive amounts of new code are flowing into Guix from upstream
projects on a daily basis, almost none of which is checked for
FSDG-compliance ahead of time. It is widely acknowledged, even in the
FSDG document itself, that the most we can realistically hope to do is
to pledge to fix FSDG-compliance problems in a timely fashion if they
are brought to our attention.

Secondly, I think you're exaggerating the remaining risk.

I acknowledge that before these discussions began, the risk of
introducing new blobs was as high as 3% per Linux-libre update, which I
agree was too high. However, we've made several important changes since
then. Most importantly, I pledged to either wait for Linux-libre
updates or to manually check for new blobs, and you introduced a
'deblob-check' pass in 'make-linux-libre-source'. Leo also made changes
to eliminate the risk of old deblob scripts being accidentally used.

It seems to me that these changes already reduce the risk of
accidentally introducing new blobs in our Linux-libre packages to near
zero, and probably at least an order of magnitude less than the risk of
non-FSDG-compliant code being introduced in, e.g., ungoogled-chromium.

Toggle quote (4 lines)
> It'd be oversimplifying to say that the Linux-libre developers just
> run their scripts to produce a release; they also manually screen the
> new upstream changes and update their scripts accordingly.

Agreed, and we now account for that by either (1) waiting for them to
certify a new release or (2) checking manually for blobs ourselves.

Toggle quote (4 lines)
> To give due credit to their efforts, we should not simply run their
> scripts with a newer version/commit of Linux and expect arriving at a
> correct result.

I've already agreed not to do that anymore.

It seems to me that some of these arguments are outdated, based on our
practices from before these discussions began.

Toggle quote (6 lines)
>> In my opinion, at minimum, the 'linux-libre-upstream-source' argument to
>> 'make-linux-libre-source' should optional.
>
> Perhaps, like for the change proposed by Leo, the edge case of bisecting
> per-commit could be accommodated by reverting this patch when needed?

That can be done easily for Leo's patch, but not for yours.

In the case of Leo's patch, if I choose to manually check for new blobs,
I can simply change one line in a 'deblob-script-X.Y' definition, like
this:

Toggle snippet (9 lines)
(define-public linux-libre-5.8-version "5.8.7")
(define deblob-scripts-5.8
(linux-libre-deblob-scripts
- linux-libre-5.8-version
+ "5.8.6"
(base32 "07z7sglyrfh0706icqqf3shadf638pvyid9386r661ds5lbsa2mw")
(base32 "0j6jba5fcddqlb42f95gjl78jisfla4nswqila074gglcrbnl9q7")))

In contrast, your patch changes the 'make-linux-libre-source' procedure
to *require* an existing 'linux-libre' tarball that precisely matches
what it's going to produce. In other words, it removes the ability to
produce a new tarball, and has been reduced to merely being a verifier
of pre-existing tarballs.

Reverting those changes would not only be extremely invasive for a
simple micro kernel update, but would also, as a side effect, entail
redeblobing and rebuilding *every* version of linux-libre in Guix, even
if only one or two of the kernels needed updates.

I guess from my perspective, I see a lot of disadvantages:
disempowerment of users, occasional unnecessary delays on the order of
tens of hours to deploy security updates, not to mention having to do
another expensive git checkout and comparison on every kernel build, and
for what?

The main argument in favor, namely to reduce the risk of blobs being
accidentally included in our kernel updates, seems to be adequately
addressed by (1) my pledge to either wait or to check for blobs myself,
and (2) the recently-added 'deblob-check' invocation in
'make-linux-libre-source'. Do you think these are insufficient?

Thanks again for this discussion, and for the work you've already done
to improve our deblobbing.

Regards,
Mark
M
M
Maxim Cournoyer wrote on 11 Sep 2020 03:53
(name . Mark H Weaver)(address . mhw@netris.org)
875z8l84fu.fsf@gmail.com
Hello Mark,

Sorry for the delayed reply.

Mark H Weaver <mhw@netris.org> writes:

Toggle quote (5 lines)
> Hi Maxim,
>
> Thanks again for the patches that you've already pushed.
> They are a great improvement.

Thank you for the kind words.

Toggle quote (17 lines)
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
>> Mark H Weaver <mhw@netris.org> writes:
>>
>>> I'm opposed to it because it would make it prohibitively difficult to
>>> push micro kernel updates (most of which contain potential security
>>> fixes) before Linux-libre has published their tarball release.
>>
>> Following recent discussions, I had understood that you agreed to wait
>> for the Linux-libre releases before bumping our own releases.
>
> Sorry, but that's incorrect. I agreed to either wait or to look for new
> blobs myself. I've already exercised that second option a couple of
> times since making that pledge. I've found it to be quite easy. The
> overwhelming majority of commits to the stable branches are bug fixes
> that obviously do not add anything resembling a blob.

Thanks for clarifying the option you chose.

Toggle quote (5 lines)
> If you haven't already done so, I'd encourage you to look over the
> upstream commits between two consecutive upstream stable releases, to
> see more concretely what I'm talking about, and how straightforward it
> is to conclude that no new blobs could possibly have been added.

I just did for v5.4.8..v5.4.9 and v5.8.5..v5.8.6. The human brain is
quite good at spotting patterns, so it wasn't too difficult indeed, but
the bug fix releases had a rather large number of commits (191 and 254,
respectively). That's a serious commitment to make.

Toggle quote (10 lines)
>> It seems the Linux-libre releases occur fast enough to not pose much
>> of a security issue; below is what I did to arrive to this conclusion.
>
> The timestamp data you collected is clearly off by several hours. It
> appears to show that over two thirds of linux-libre releases come out
> *before* the corresponding linux release. One third of them appear to
> have come out more than 4 hours before the corresponding linux release.
> That cannot be right. I guess someone's clock is off by several hours,
> or somehow the timezones are not being taken into account.

The git commands I used are supposed to take the timezones into account
(converting the author dates into my local time), but as you mentioned
something seems off.

Toggle quote (22 lines)
> I can tell you that within the last couple of weeks, since my pledge to
> either wait for linux-libre or to check for blobs myself, I very clearly
> remember upstream updates being tagged a few hours after midnight one
> morning, and that it was not until after dark the next evening before
> linux-libre had tagged their releases. That instance is not reflected
> in the data you collected, which again suggests to me that there's a
> very significant systemic error in that data.
>
> Even with this apparently large bias in the data, it shows that
> linux-libre-5.7.7 was tagged almost 22 hours after the corresponding
> linux release. Most likely that was actually at least 28 hours.
>
> Please don't misunderstand me: I do not fault the Linux-libre developers
> for not being quick enough. On the contrary, they've been consistently
> *excellent* in that regard for as long as I've been paying attention. I
> certainly don't fault them for occasionally spending some time away from
> their computers.
>
> What I _do_ fault them for is *insisting* on placing themselves in the
> middle of what should be a fast path for security updates from the
> upstream developers to us.

I agree that it is sub-optimal, but I don't see how that could be made
differently, with upstream Linux being at odds with our ideals. We
can't have it both ways.

Toggle quote (15 lines)
> To my mind, the practices that the Linux-libre developers are attempting
> to impose on us feel like Service as a Software Substitute (SaaSS), but
> in this case enforced by social pressure (and the suggestion that it
> might violate the GNU FSDG) instead of the usual technical restrictions.
>
> I'll also note that what you're proposing will apparently not be enough
> to satisfy Jason and Alexandre. They've gone so far as to suggest that
> it's improper for an FSDG-compliant distribution to ever download
> non-FSDG-compliant source code to a user machine. It seems that to
> satisfy them, Guix developers would apparently need to host our own
> distribution site for cleaned-up copies of source tarballs, and to use
> some separate tools to produce and upload new source tarballs to this
> site for every update of software whose upstream source is not
> FSDG-compliant.

I've reached the same conclusion, after engaging with them in the
#linux-libre channel. To my understanding, we are not violating the
current GNU FSDG. The spirit of the FSDG, as I understand it, is
basically "don't thwart users towards nonfree software". I don't think
downloading a nonfree archive with the objective of turning it into free
software counts as such. To the contrary, it can be seen as some form
of empowerment of how the process of freeing the software they use work,
enabling them to more directly improve such process.

I'd really like someone explain to me how the process of cleaning
nonfree software into free software can be considered a freedom issue.
So far the people I've asked either support their argument using their
personal interpretation of the FSDG or simply do not produce an answer.

[...]

Toggle quote (15 lines)
>>> also make it prohibitively difficult to perform deblobbed bisections
>>> between two adjacent versions from the upstream stable git repository.
>>
>> In my opinion, we should not trade our correctness guarantee in exchange
>> for convenience,
>
> First, I think that it's a mistake to suggest that any "correctness
> guarantee" exists or could exist in Guix, with or without your proposed
> patch. Massive amounts of new code are flowing into Guix from upstream
> projects on a daily basis, almost none of which is checked for
> FSDG-compliance ahead of time. It is widely acknowledged, even in the
> FSDG document itself, that the most we can realistically hope to do is
> to pledge to fix FSDG-compliance problems in a timely fashion if they
> are brought to our attention.

I agree about the broader FSDG-compliance correctness guarantee. I'm
sorry if I was unclear, but what I meant was in the more narrow sense of
correctness w.r.t. the official Linux-libre releases.

Toggle quote (10 lines)
> Secondly, I think you're exaggerating the remaining risk.
>
> I acknowledge that before these discussions began, the risk of
> introducing new blobs was as high as 3% per Linux-libre update, which I
> agree was too high. However, we've made several important changes since
> then. Most importantly, I pledged to either wait for Linux-libre
> updates or to manually check for new blobs, and you introduced a
> 'deblob-check' pass in 'make-linux-libre-source'. Leo also made changes
> to eliminate the risk of old deblob scripts being accidentally used.

Those are good improvements, yes. My fear is that the amount of
complexity upgrading our Linux-libre package is starting to reach
unwieldy levels. Consider a newcomer wanting to upgrade our Linux-libre
package. They bump the sources. Run 'make defconfig'. Successfully
build a kernel. Send a patch. One of us reviews it, it looks OK, gets
merged. It's easy to see what can silently go wrong. I'd prefer
leaving the Linux-libre team handle that complexity rather than
duplicate it.

[...]

Toggle quote (26 lines)
>>> In my opinion, at minimum, the 'linux-libre-upstream-source' argument to
>>> 'make-linux-libre-source' should optional.
>>
>> Perhaps, like for the change proposed by Leo, the edge case of bisecting
>> per-commit could be accommodated by reverting this patch when needed?
>
> That can be done easily for Leo's patch, but not for yours.
>
> In the case of Leo's patch, if I choose to manually check for new blobs,
> I can simply change one line in a 'deblob-script-X.Y' definition, like
> this:
>
> (define-public linux-libre-5.8-version "5.8.7")
> (define deblob-scripts-5.8
> (linux-libre-deblob-scripts
> - linux-libre-5.8-version
> + "5.8.6"
> (base32 "07z7sglyrfh0706icqqf3shadf638pvyid9386r661ds5lbsa2mw")
> (base32 "0j6jba5fcddqlb42f95gjl78jisfla4nswqila074gglcrbnl9q7")))
>
> In contrast, your patch changes the 'make-linux-libre-source' procedure
> to *require* an existing 'linux-libre' tarball that precisely matches
> what it's going to produce. In other words, it removes the ability to
> produce a new tarball, and has been reduced to merely being a verifier
> of pre-existing tarballs.

I think that's a good thing, at least for the usual use case. But now
that you've mentioned that there *is* an occasional need to push
security updates faster than the Linux-libre official releases can
allow, I've modified the patch to make it optional, as you suggested.
I'd suggest that disabling that check be only allowed for seasoned
linux-libre maintainers such as you or Leo, and only when strictly
necessary (serious security threats affecting the Guix System and no
Linux-libre release yet). Any other casual "bump" should fully make use
of the verification machinery.

Toggle quote (5 lines)
> Reverting those changes would not only be extremely invasive for a
> simple micro kernel update, but would also, as a side effect, entail
> redeblobing and rebuilding *every* version of linux-libre in Guix, even
> if only one or two of the kernels needed updates.

I was only considering reverting this as a local hack in the context of
per-commit bisection.

Toggle quote (6 lines)
> I guess from my perspective, I see a lot of disadvantages:
> disempowerment of users, occasional unnecessary delays on the order of
> tens of hours to deploy security updates, not to mention having to do
> another expensive git checkout and comparison on every kernel build, and
> for what?

This ensures we benefit from the experience of the Linux-libre
developers in screening the Linux sources for new nonfree threats.

Toggle quote (6 lines)
> The main argument in favor, namely to reduce the risk of blobs being
> accidentally included in our kernel updates, seems to be adequately
> addressed by (1) my pledge to either wait or to check for blobs myself,
> and (2) the recently-added 'deblob-check' invocation in
> 'make-linux-libre-source'. Do you think these are insufficient?

The trust chain is made simpler if we validate the Linux-libre result
(i.e. we need only trust the Linux-libre project). As it is used by a
number of distros, we can hope for any mistake they might do to be
quickly flagged. If we choose instead to generate our own Linux-libre
releases, doing our own "development", then people need to trust you or
Leo, or whoever bumped the linux-libre package for having done due
diligence (screening new commits for nonfree code). With all due
respect, it seems easier to put our trust in the Linux-libre project for
this task, as this is their purpose and they have greater exposure.

Toggle quote (3 lines)
> Thanks again for this discussion, and for the work you've already done
> to improve our deblobbing.

I'm equally thankful to you for your patience in handling all these
discussions, and for sticking around after all these years, keeping the
flow of kernel and icecat updates (amongst other) coming!

Please see the revised patch which I'll git send-email shortly.

Maxim
M
M
Maxim Cournoyer wrote on 11 Sep 2020 16:44
[PATCH v3 1/2] gnu: linux-libre: Compare generated sources against Linux-libre releases.
(address . 43160@debbugs.gnu.org)
20200911144459.27220-1-maxim.cournoyer@gmail.com
* gnu/packages/linux.scm (make-linux-libre-source): Rename the UPSTREAM-SOURCE
parameter to LINUX-UPSTREAM-SOURCE. Add a new LINUX-LIBRE-UPSTREAM-SOURCE
parameter. Update doc. Adjust variable names. Capitalize "Linux" in the
user messages. Remove empty directories from the generated sources, then
invoke diff between these sources and those of the corresponding Linux-libre
release, unless LINUX-LIBRE-UPSTREAM-SOURCE is #f.
(%upstream-linux-source): Convert the hash as base32 inside the definition, to
simplify its use.
(%upstream-linux-libre-source): New procedure.
(linux-libre-5.8-pristine-source): Add a LIBRE-HASH binding and use it with
%UPSTREAM-LINUX-LIBRE-SOURCE to provide the Linux-libre release origin to the
make-linux-libre-source procedure call.
(linux-libre-5.4-pristine-source): Likewise.
(linux-libre-4.19-pristine-source): Likewise.
(linux-libre-4.14-pristine-source): Likewise.
(linux-libre-4.9-pristine-source): Likewise.
(linux-libre-4.4-pristine-source): Likewise.
---
gnu/packages/linux.scm | 79 ++++++++++++++++++++++++++++++++----------
1 file changed, 61 insertions(+), 18 deletions(-)

Toggle diff (171 lines)
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 72fb3ca49d..1df66330cb 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -221,10 +221,18 @@ from forcing GEXP-PROMISE."
#:guile-for-build guile)))
(define (make-linux-libre-source version
- upstream-source
+ linux-upstream-source
+ linux-libre-upstream-source
deblob-scripts)
"Return a 'computed' origin that generates a Linux-libre tarball from the
-corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
+corresponding LINUX-UPSTREAM-SOURCE (an origin), using the given
+DEBLOB-SCRIPTS. The generated Linux-libre source is compared against the
+corresponding LINUX-LIBRE-UPSTREAM-SOURCE upstream release (an origin), to
+ensure correctness. This comparison is skipped when
+LINUX-LIBRE-UPSTREAM-SOURCE is set to #f. This can be used in exceptional
+cases where for security reasons an update must be pushed before the
+Linux-libre project could publish a cleaned up tree. Manual screening of the
+new Linux changes for nonfree code is required when skipping the comparison."
(match deblob-scripts
((deblob-version (? origin? deblob) (? origin? deblob-check))
(unless (string=? deblob-version (version-major+minor version))
@@ -281,14 +289,14 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
(("/bin/sed") (which "sed"))
(("/usr/bin/python") (which "python"))))
- (if (file-is-directory? #+upstream-source)
+ (if (file-is-directory? #+linux-upstream-source)
(begin
- (format #t "Copying upstream linux source...~%")
- (invoke "cp" "--archive" #+upstream-source dir)
+ (format #t "Copying upstream Linux source...~%")
+ (invoke "cp" "--archive" #+linux-upstream-source dir)
(invoke "chmod" "--recursive" "u+w" dir))
(begin
- (format #t "Unpacking upstream linux tarball...~%")
- (invoke "tar" "xf" #$upstream-source)
+ (format #t "Unpacking upstream Linux tarball...~%")
+ (invoke "tar" "xf" #$linux-upstream-source)
(match (scandir "."
(lambda (name)
(and (not (member name '("." "..")))
@@ -315,7 +323,22 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
(format #t "~%Scanning the generated tarball for blobs...~%")
(invoke "/tmp/bin/deblob-check" "--use-awk" "--list-blobs"
- #$output))))))))))
+ #$output)
+
+ (if #+linux-libre-upstream-source
+ (begin
+
+ ;; Git doesn't track empty directories, so remove them
+ ;; from our local tree for the sake of comparison.
+ (invoke "find" dir "-type" "d" "-empty" "-delete")
+ (invoke "diff" "-ur"
+ dir
+ #+linux-libre-upstream-source))
+ (begin
+ (format #t "~%Skipping comparison with the upstream \
+Linux-libre release... Ensure new sources have been manually verified \
+against nonfree software.~%")
+ #t)))))))))))
;;;
@@ -344,8 +367,16 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
(uri (string-append "mirror://kernel.org"
"/linux/kernel/v" (version-major version) ".x/"
"linux-" version ".tar.xz"))
- (sha256 hash)))
+ (sha256 (base32 hash))))
+(define (%upstream-linux-libre-source version hash)
+ (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "git://linux-libre.fsfla.org/releases.git")
+ (commit (string-append "sources/v" version "-gnu"))))
+ (file-name (git-file-name "linux-libre-source" version))
+ (sha256 (base32 hash))))
;; The current "stable" kernel. That is, the most recently released major
;; version.
@@ -357,9 +388,11 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
(base32 "0j6jba5fcddqlb42f95gjl78jisfla4nswqila074gglcrbnl9q7")))
(define-public linux-libre-5.8-pristine-source
(let ((version linux-libre-5.8-version)
- (hash (base32 "0xm901zvvrwsb9k88la6pb65nybi43bygiyz1z68njwsx6ripxik")))
+ (hash "0xm901zvvrwsb9k88la6pb65nybi43bygiyz1z68njwsx6ripxik")
+ (libre-hash "0zjw82xrmlgmjb5w0ar4mhjsn9pf8halwzq6dvv71hmrmskjxbyn"))
(make-linux-libre-source version
(%upstream-linux-source version hash)
+ (%upstream-linux-libre-source version libre-hash)
deblob-scripts-5.8)))
;; The "longterm" kernels — the older releases with long-term upstream support.
@@ -373,10 +406,12 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
(base32 "1b3q88i2qfdxyvpi9f7jds0qlb8hfpw87mgia096ax6822c2cmyb")))
(define-public linux-libre-5.4-pristine-source
(let ((version linux-libre-5.4-version)
- (hash (base32 "1vymhl6p7i06gfgpw9iv75bvga5sj5kgv46i1ykqiwv6hj9w5lxr")))
- (make-linux-libre-source version
- (%upstream-linux-source version hash)
- deblob-scripts-5.4)))
+ (hash "1vymhl6p7i06gfgpw9iv75bvga5sj5kgv46i1ykqiwv6hj9w5lxr")
+ (libre-hash "150cz1h9cn8klh8dhnbhb9zmxc6pf6x9rj5fa2wv9k7r42lk9kis"))
+ (make-linux-libre-source version
+ (%upstream-linux-source version hash)
+ (%upstream-linux-libre-source version libre-hash)
+ deblob-scripts-5.4)))
(define-public linux-libre-4.19-version "4.19.144")
(define deblob-scripts-4.19
@@ -386,9 +421,11 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
(base32 "1jiaw0as1ippkrjdpd52657w5mz9qczg3y2hlra7m9k0xawwiqlf")))
(define-public linux-libre-4.19-pristine-source
(let ((version linux-libre-4.19-version)
- (hash (base32 "0jnj65bdy5y9lcj5zhrn4iaszpww8z41ac66j00l75sd931l1g9k")))
+ (hash "0jnj65bdy5y9lcj5zhrn4iaszpww8z41ac66j00l75sd931l1g9k")
+ (libre-hash "04lijps8qjk3kwsgvkw9plhmy5rxgrp6ld82d96jgjm27s5xd308"))
(make-linux-libre-source version
(%upstream-linux-source version hash)
+ (%upstream-linux-libre-source version libre-hash)
deblob-scripts-4.19)))
(define-public linux-libre-4.14-version "4.14.197")
@@ -399,9 +436,11 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
(base32 "1qij18inijj6c3ma8hv98yjagnzxdxyn134da9fd23ky8q6hbvky")))
(define-public linux-libre-4.14-pristine-source
(let ((version linux-libre-4.14-version)
- (hash (base32 "029h46yki2hxdbn7afmnf3yar1pnwrpszx76irsa5mf8gnrasyp0")))
+ (hash "029h46yki2hxdbn7afmnf3yar1pnwrpszx76irsa5mf8gnrasyp0")
+ (libre-hash "1hbp1shhhifk3xy8026c466vpfpgll11xx1kawq97llx1pars4hn"))
(make-linux-libre-source version
(%upstream-linux-source version hash)
+ (%upstream-linux-libre-source version libre-hash)
deblob-scripts-4.14)))
(define-public linux-libre-4.9-version "4.9.235")
@@ -412,9 +451,11 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
(base32 "0fxajshb75siq39lj5h8xvhdj8lcmddkslwlyj65rhlwk6g2r4b2")))
(define-public linux-libre-4.9-pristine-source
(let ((version linux-libre-4.9-version)
- (hash (base32 "1hqcb3zw4546h6x5xy2mywdznha8813lx15mxbgfbvwm4qhsc9g6")))
+ (hash "1hqcb3zw4546h6x5xy2mywdznha8813lx15mxbgfbvwm4qhsc9g6")
+ (libre-hash "0sz73pxdz4kl4fyfvbkm7xzdhzx8x2xajr93mhapc65hssyz3059"))
(make-linux-libre-source version
(%upstream-linux-source version hash)
+ (%upstream-linux-libre-source version libre-hash)
deblob-scripts-4.9)))
(define-public linux-libre-4.4-version "4.4.235")
@@ -425,9 +466,11 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
(base32 "0hhin1jpfkd6nwrb6xqxjzl3hdxy4pn8a15hy2d3d83yw6pflbsf")))
(define-public linux-libre-4.4-pristine-source
(let ((version linux-libre-4.4-version)
- (hash (base32 "0w5pkv936zb0shjgnpv17gcp5n8f91djznzq54p6j1bl5q2qdyqd")))
+ (hash "0w5pkv936zb0shjgnpv17gcp5n8f91djznzq54p6j1bl5q2qdyqd")
+ (libre-hash "1pydy3cr4malqlr69ksw22nphpydfmpbrfh190ahgym741zdfncg"))
(make-linux-libre-source version
(%upstream-linux-source version hash)
+ (%upstream-linux-libre-source version libre-hash)
deblob-scripts-4.4)))
(define %boot-logo-patch
--
2.28.0
M
M
Maxim Cournoyer wrote on 11 Sep 2020 16:44
[PATCH v3 2/2] linux-libre: Enable multi-core xz compression during tarball generation.
(address . 43160@debbugs.gnu.org)
20200911144459.27220-2-maxim.cournoyer@gmail.com
* gnu/packages/linux.scm (make-linux-libre-source): Add an NCORES binding, and
use it to configure the number of threads xz should use via the XZ_DEFAULTS
environment variable.
---
gnu/packages/linux.scm | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

Toggle diff (26 lines)
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 1df66330cb..d6441fa181 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -255,7 +255,8 @@ new Linux changes for nonfree code is required when skipping the comparison."
(setvbuf (current-output-port) 'line)
- (let ((dir (string-append "linux-" #$version)))
+ (let ((dir (string-append "linux-" #$version))
+ (ncores (number->string (parallel-job-count))))
(mkdir "/tmp/bin")
(set-path-environment-variable
@@ -289,6 +290,9 @@ new Linux changes for nonfree code is required when skipping the comparison."
(("/bin/sed") (which "sed"))
(("/usr/bin/python") (which "python"))))
+ ;; This enables xz multi-core compression/decompression.
+ (setenv "XZ_DEFAULTS" (string-append "--threads=" ncores))
+
(if (file-is-directory? #+linux-upstream-source)
(begin
(format #t "Copying upstream Linux source...~%")
--
2.28.0
M
M
Mark H Weaver wrote on 12 Sep 2020 19:07
Re: [PATCH v3 1/2] gnu: linux-libre: Compare generated sources against Linux-libre releases.
87tuw2exex.fsf@netris.org
I've grown tired of arguing about this. You have the authority, so do
as you will, and I will take my leave from maintenance of the kernel
packages. Thanks for asking my opinion, anyway.

Mark
M
M
Maxim Cournoyer wrote on 14 Sep 2020 01:50
(name . Mark H Weaver)(address . mhw@netris.org)
87sgbl5j94.fsf@gmail.com
Hello Mark,

Mark H Weaver <mhw@netris.org> writes:

Toggle quote (6 lines)
> I've grown tired of arguing about this. You have the authority, so do
> as you will, and I will take my leave from maintenance of the kernel
> packages. Thanks for asking my opinion, anyway.
>
> Mark

I was hoping this latest modified patch would meet both our goals
(strictly verified for the usual case, with an option to switch to
manual verification of the kernel sources for the exceptional security
quick releases).

Sorry to have worn you out on this. I'll leave 2 weeks for the issue to
settle, hoping you might reconsider.

Thanks again,

Maxim
M
M
Mark H Weaver wrote on 15 Sep 2020 12:33
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87mu1rba81.fsf@netris.org
Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

Toggle quote (16 lines)
> Mark H Weaver <mhw@netris.org> writes:
>
>> I've grown tired of arguing about this. You have the authority, so do
>> as you will, and I will take my leave from maintenance of the kernel
>> packages. Thanks for asking my opinion, anyway.
>>
>> Mark
>
> I was hoping this latest modified patch would meet both our goals
> (strictly verified for the usual case, with an option to switch to
> manual verification of the kernel sources for the exceptional security
> quick releases).
>
> Sorry to have worn you out on this. I'll leave 2 weeks for the issue to
> settle, hoping you might reconsider.

I appreciate that. I'll attempt another followup in the next few days.

Mark
M
M
Maxim Cournoyer wrote on 28 Sep 2020 05:59
control message for bug #43160
(address . control@debbugs.gnu.org)
87imbypn40.fsf@gmail.com
retitle 43160 linux-libre: compare guix-generated sources against upstream releases
quit
M
M
Mark H Weaver wrote on 22 Apr 2021 08:35
Re: [PATCH v3 1/2] gnu: linux-libre: Compare generated sources against Linux-libre releases.
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87eef225d4.fsf@netris.org
Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

Toggle quote (8 lines)
> I was hoping this latest modified patch would meet both our goals
> (strictly verified for the usual case, with an option to switch to
> manual verification of the kernel sources for the exceptional security
> quick releases).
>
> Sorry to have worn you out on this. I'll leave 2 weeks for the issue to
> settle, hoping you might reconsider.

I'm sorry for not following up on this sooner. My opinion on this issue
has not changed, but I've run out of energy to continue arguing about
it, and anyway it's probably more important to make the Linux-libre
developers happy. Do as you think best, and I'll make adjustments on my
private branch as needed.

Thanks,
Mark
M
M
Maxim Cournoyer wrote on 27 Jul 2023 18:18
Re: bug#43160: linux-libre: compare guix-generated sources against upstream releases
(name . Mark H Weaver)(address . mhw@netris.org)
873519z5sm.fsf_-_@gmail.com
Hi Mark,

Mark H Weaver <mhw@netris.org> writes:

Toggle quote (18 lines)
> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
>> I was hoping this latest modified patch would meet both our goals
>> (strictly verified for the usual case, with an option to switch to
>> manual verification of the kernel sources for the exceptional security
>> quick releases).
>>
>> Sorry to have worn you out on this. I'll leave 2 weeks for the issue to
>> settle, hoping you might reconsider.
>
> I'm sorry for not following up on this sooner. My opinion on this issue
> has not changed, but I've run out of energy to continue arguing about
> it, and anyway it's probably more important to make the Linux-libre
> developers happy. Do as you think best, and I'll make adjustments on my
> private branch as needed.

I think there's still value in this series, but due to the already high
build requirements of running the verification script, I don't think
adding more to it is a good idea.

A better idea will be to build straight from the Git Linux-libre
repository, which will lighten the load to build these kernels while
simplifying things a bit.

Closing for now.

--
Thanks,
Maxim
Closed
?