Package: guix-patches;
Reported by: Ludovic Courtès <ludo <at> gnu.org>
Date: Sun, 13 May 2018 22:24:02 UTC
Severity: normal
Tags: patch
To reply to this bug, email your comments to 31442 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
guix-patches <at> gnu.org:bug#31442; Package guix-patches.
(Sun, 13 May 2018 22:24:02 GMT) Full text and rfc822 format available.Ludovic Courtès <ludo <at> gnu.org>:guix-patches <at> gnu.org.
(Sun, 13 May 2018 22:24:02 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Ludovic Courtès <ludo <at> gnu.org> To: guix-patches <at> gnu.org Cc: Ludovic Courtès <ludo <at> gnu.org> Subject: [PATCH 0/5] 'guix health': a tool to report vulnerable packages Date: Sun, 13 May 2018 22:25:25 +0200
Hello Guix! On IRC davidl shared a shell script that checks the output of ‘guix lint -c cve’ and uses that to determine vulnerable packages in a profile. That reminds me of the plan for ‘guix health’ (a tool to do just that), so I went ahead and tried to make it a reality at last. This ‘guix health’ reports information about “leaf” packages in a profile, but not about their dependencies: --8<---------------cut here---------------start------------->8--- $ ./pre-inst-env guix health -p /run/current-system/profile/ guix health: warning: util-linux <at> 2.31.1 may be vulnerable to CVE-2018-7738 guix health: warning: util-linux <at> 2.31.1 is available but does not fix any of these hint: Run `guix pull' and then re-run `guix health' to see if fixes are available. If none are available, please consider submitting a patch for the package definition of 'util-linux'. guix health: warning: shadow <at> 4.5 may be vulnerable to CVE-2018-7169 guix health: warning: shadow <at> 4.6 is available and fixes CVE-2018-7169, consider ugprading guix health: warning: tar <at> 1.29 may be vulnerable to CVE-2016-6321 guix health: warning: tar <at> 1.29 is available but does not fix any of these hint: Run `guix pull' and then re-run `guix health' to see if fixes are available. If none are available, please consider submitting a patch for the package definition of 'tar'. --8<---------------cut here---------------end--------------->8--- The difficulty here is that we need to know a package’s CPE name before we can check the CVE database, and we also need to know whether the package already includes fixes for known CVEs. This patch set attaches this information to manifest entries, so that ‘guix health’ can then rely on it. Fundamentally, that means we cannot reliably tell much about dependencies: in cases where the CPE name differs from the Guix name, we won’t have any match, and more generally, we cannot know what CVE are patched in the package; we could infer part of this by looking at the same-named package in the current Guix, but that’s hacky. I think that longer-term we probably need to attach this kind of meta-data to packages themselves, by adding a bunch of files in each package, say under PREFIX/guix. We could do that for search paths as well. Should we satisfy ourselves with the current approach in the meantime? Thoughts? Besides, support for properties in manifest entries seems useful to me, so we may want to keep it regardless of whether we take ‘guix health’ as-is. Ludo’. Ludovic Courtès (5): profiles: Add '%current-profile', 'user-friendly-profile', & co. packages: Add 'package-patched-vulnerabilities'. profiles: Add 'properties' field to manifest entries. profiles: Record fixed vulnerabilities as properties of entries. DRAFT Add 'guix health'. Makefile.am | 1 + guix/packages.scm | 28 +++++++ guix/profiles.scm | 91 ++++++++++++++++++++-- guix/scripts/health.scm | 158 +++++++++++++++++++++++++++++++++++++++ guix/scripts/lint.scm | 23 +----- guix/scripts/package.scm | 40 ---------- po/guix/POTFILES.in | 1 + tests/packages.scm | 15 ++++ tests/profiles.scm | 22 ++++++ 9 files changed, 312 insertions(+), 67 deletions(-) create mode 100644 guix/scripts/health.scm -- 2.17.0
guix-patches <at> gnu.org:bug#31442; Package guix-patches.
(Mon, 14 May 2018 08:27:02 GMT) Full text and rfc822 format available.Message #8 received at 31442 <at> debbugs.gnu.org (full text, mbox):
From: Ludovic Courtès <ludo <at> gnu.org> To: 31442 <at> debbugs.gnu.org Cc: Ludovic Courtès <ludo <at> gnu.org> Subject: [PATCH 3/5] profiles: Add 'properties' field to manifest entries. Date: Mon, 14 May 2018 10:25:48 +0200
* guix/profiles.scm (<manifest-entry>)[properties]: New field.
(manifest->gexp)[entry->gexp]: Serialize it.
(sexp->manifest)[sexp->manifest-entry]: Deserialize it.
---
guix/profiles.scm | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/guix/profiles.scm b/guix/profiles.scm
index 3cdc3d2f1..02828e465 100644
--- a/guix/profiles.scm
+++ b/guix/profiles.scm
@@ -78,6 +78,7 @@
manifest-entry-dependencies
manifest-entry-search-paths
manifest-entry-parent
+ manifest-entry-properties
manifest-pattern
manifest-pattern?
@@ -181,7 +182,9 @@
(search-paths manifest-entry-search-paths ; search-path-specification*
(default '()))
(parent manifest-entry-parent ; promise (#f | <manifest-entry>)
- (default (delay #f))))
+ (default (delay #f)))
+ (properties manifest-entry-properties ; list of symbol/value pairs
+ (default '())))
(define-record-type* <manifest-pattern> manifest-pattern
make-manifest-pattern
@@ -320,18 +323,20 @@ denoting a specific output of a package."
(define (entry->gexp entry)
(match entry
(($ <manifest-entry> name version output (? string? path)
- (deps ...) (search-paths ...))
+ (deps ...) (search-paths ...) _ (properties ...))
#~(#$name #$version #$output #$path
(propagated-inputs #$(map entry->gexp deps))
(search-paths #$(map search-path-specification->sexp
- search-paths))))
+ search-paths))
+ (properties . #$properties)))
(($ <manifest-entry> name version output package
- (deps ...) (search-paths ...))
+ (deps ...) (search-paths ...) _ (properties ...))
#~(#$name #$version #$output
(ungexp package (or output "out"))
(propagated-inputs #$(map entry->gexp deps))
(search-paths #$(map search-path-specification->sexp
- search-paths))))))
+ search-paths))
+ (properties . #$properties)))))
(match manifest
(($ <manifest> (entries ...))
@@ -394,7 +399,9 @@ procedure is here for backward-compatibility and will eventually vanish."
(dependencies deps*)
(search-paths (map sexp->search-path-specification
search-paths))
- (parent parent))))
+ (parent parent)
+ (properties (or (assoc-ref extra-stuff 'properties)
+ '())))))
entry))))
(match sexp
--
2.17.0
guix-patches <at> gnu.org:bug#31442; Package guix-patches.
(Mon, 14 May 2018 08:27:03 GMT) Full text and rfc822 format available.Message #11 received at 31442 <at> debbugs.gnu.org (full text, mbox):
From: Ludovic Courtès <ludo <at> gnu.org> To: 31442 <at> debbugs.gnu.org Cc: Ludovic Courtès <ludo <at> gnu.org> Subject: [PATCH 1/5] profiles: Add '%current-profile', 'user-friendly-profile', & co. Date: Mon, 14 May 2018 10:25:46 +0200
* guix/scripts/package.scm (%user-profile-directory)
(%profile-directory, %current-profile, canonicalize-profile)
(user-friendly-profile): Move to...
* guix/profiles.scm: ... here.
---
guix/profiles.scm | 49 +++++++++++++++++++++++++++++++++++++++-
guix/scripts/package.scm | 40 --------------------------------
2 files changed, 48 insertions(+), 41 deletions(-)
diff --git a/guix/profiles.scm b/guix/profiles.scm
index dca247976..3cdc3d2f1 100644
--- a/guix/profiles.scm
+++ b/guix/profiles.scm
@@ -25,6 +25,7 @@
;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.
(define-module (guix profiles)
+ #:use-module ((guix config) #:select (%state-directory))
#:use-module ((guix utils) #:hide (package-name->name+version))
#:use-module ((guix build utils)
#:select (package-name->name+version))
@@ -118,7 +119,13 @@
generation-file-name
switch-to-generation
roll-back
- delete-generation))
+ delete-generation
+
+ %user-profile-directory
+ %profile-directory
+ %current-profile
+ canonicalize-profile
+ user-friendly-profile))
;;; Commentary:
;;;
@@ -1465,4 +1472,44 @@ because the NUMBER is zero.)"
(else
(delete-and-return)))))
+(define %user-profile-directory
+ (and=> (getenv "HOME")
+ (cut string-append <> "/.guix-profile")))
+
+(define %profile-directory
+ (string-append %state-directory "/profiles/"
+ (or (and=> (or (getenv "USER")
+ (getenv "LOGNAME"))
+ (cut string-append "per-user/" <>))
+ "default")))
+
+(define %current-profile
+ ;; Call it `guix-profile', not `profile', to allow Guix profiles to
+ ;; coexist with Nix profiles.
+ (string-append %profile-directory "/guix-profile"))
+
+(define (canonicalize-profile profile)
+ "If PROFILE is %USER-PROFILE-DIRECTORY, return %CURRENT-PROFILE. Otherwise
+return PROFILE unchanged. The goal is to treat '-p ~/.guix-profile' as if
+'-p' was omitted." ; see <http://bugs.gnu.org/17939>
+
+ ;; Trim trailing slashes so that the basename comparison below works as
+ ;; intended.
+ (let ((profile (string-trim-right profile #\/)))
+ (if (and %user-profile-directory
+ (string=? (canonicalize-path (dirname profile))
+ (dirname %user-profile-directory))
+ (string=? (basename profile) (basename %user-profile-directory)))
+ %current-profile
+ profile)))
+
+(define (user-friendly-profile profile)
+ "Return either ~/.guix-profile if that's what PROFILE refers to, directly or
+indirectly, or PROFILE."
+ (if (and %user-profile-directory
+ (false-if-exception
+ (string=? (readlink %user-profile-directory) profile)))
+ %user-profile-directory
+ profile))
+
;;; profiles.scm ends here
diff --git a/guix/scripts/package.scm b/guix/scripts/package.scm
index 4f519e6f3..29829f52c 100644
--- a/guix/scripts/package.scm
+++ b/guix/scripts/package.scm
@@ -64,46 +64,6 @@
;;; Profiles.
;;;
-(define %user-profile-directory
- (and=> (getenv "HOME")
- (cut string-append <> "/.guix-profile")))
-
-(define %profile-directory
- (string-append %state-directory "/profiles/"
- (or (and=> (or (getenv "USER")
- (getenv "LOGNAME"))
- (cut string-append "per-user/" <>))
- "default")))
-
-(define %current-profile
- ;; Call it `guix-profile', not `profile', to allow Guix profiles to
- ;; coexist with Nix profiles.
- (string-append %profile-directory "/guix-profile"))
-
-(define (canonicalize-profile profile)
- "If PROFILE is %USER-PROFILE-DIRECTORY, return %CURRENT-PROFILE. Otherwise
-return PROFILE unchanged. The goal is to treat '-p ~/.guix-profile' as if
-'-p' was omitted." ; see <http://bugs.gnu.org/17939>
-
- ;; Trim trailing slashes so that the basename comparison below works as
- ;; intended.
- (let ((profile (string-trim-right profile #\/)))
- (if (and %user-profile-directory
- (string=? (canonicalize-path (dirname profile))
- (dirname %user-profile-directory))
- (string=? (basename profile) (basename %user-profile-directory)))
- %current-profile
- profile)))
-
-(define (user-friendly-profile profile)
- "Return either ~/.guix-profile if that's what PROFILE refers to, directly or
-indirectly, or PROFILE."
- (if (and %user-profile-directory
- (false-if-exception
- (string=? (readlink %user-profile-directory) profile)))
- %user-profile-directory
- profile))
-
(define (ensure-default-profile)
"Ensure the default profile symlink and directory exist and are writable."
--
2.17.0
guix-patches <at> gnu.org:bug#31442; Package guix-patches.
(Mon, 14 May 2018 08:27:03 GMT) Full text and rfc822 format available.Message #14 received at 31442 <at> debbugs.gnu.org (full text, mbox):
From: Ludovic Courtès <ludo <at> gnu.org> To: 31442 <at> debbugs.gnu.org Cc: Ludovic Courtès <ludo <at> gnu.org> Subject: [PATCH 4/5] profiles: Record fixed vulnerabilities as properties of entries. Date: Mon, 14 May 2018 10:25:49 +0200
* guix/profiles.scm (package->manifest-entry)[fixed, cpe-name]
[cpe-version]: New variables.
Populate the 'properties' field based on these.
* tests/profiles.scm ("manifest-entry-properties"): New test.
---
guix/profiles.scm | 23 ++++++++++++++++++++++-
tests/profiles.scm | 22 ++++++++++++++++++++++
2 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/guix/profiles.scm b/guix/profiles.scm
index 02828e465..6656cf356 100644
--- a/guix/profiles.scm
+++ b/guix/profiles.scm
@@ -286,6 +286,17 @@ file name."
(define* (package->manifest-entry package #:optional (output "out")
#:key (parent (delay #f)))
"Return a manifest entry for the OUTPUT of package PACKAGE."
+ (define fixed
+ (append (package-patched-vulnerabilities package)
+ (or (assq-ref (package-properties package) 'lint-hidden-cve)
+ '())))
+
+ (define cpe-name
+ (assoc-ref (package-properties package) 'cpe-name))
+
+ (define cpe-version
+ (assoc-ref (package-properties package) 'cpe-version))
+
;; For each dependency, keep a promise pointing to its "parent" entry.
(letrec* ((deps (map (match-lambda
((label package)
@@ -303,7 +314,17 @@ file name."
(dependencies (delete-duplicates deps))
(search-paths
(package-transitive-native-search-paths package))
- (parent parent))))
+ (parent parent)
+ (properties `(,@(if cpe-name
+ `((cpe-name . ,cpe-name))
+ '())
+ ,@(if cpe-version
+ `((cpe-version . ,cpe-version))
+ '())
+ ,@(if (null? fixed)
+ '()
+ `((fixed-vulnerabilities
+ . ,fixed))))))))
entry))
(define (packages->manifest packages)
diff --git a/tests/profiles.scm b/tests/profiles.scm
index c668c2b83..8152e4b68 100644
--- a/tests/profiles.scm
+++ b/tests/profiles.scm
@@ -439,6 +439,28 @@
#:locales? #f)))
(return #f)))))
+(test-equal "manifest-entry-properties"
+ '(((fixed-vulnerabilities "CVE-2015-1234"))
+ ((fixed-vulnerabilities "CVE-2016-1234" "CVE-2018-4567"))
+ ((cpe-name . "Pi")
+ (fixed-vulnerabilities "CVE-2002-0001"))
+ ())
+ (let ((p1 (dummy-package "pi"
+ (source (dummy-origin
+ (patches (list "/a/b/pi-CVE-2015-1234.patch"))))))
+ (p2 (dummy-package "pi"
+ (source (dummy-origin
+ (patches
+ (list
+ "/a/b/pi-CVE-2016-1234-CVE-2018-4567.patch"))))))
+ (p3 (dummy-package "pi" (source (dummy-origin))
+ (properties
+ '((cpe-name . "Pi")
+ (lint-hidden-cve "CVE-2002-0001")))))
+ (p4 (dummy-package "pi" (source (dummy-origin)))))
+ (map (compose manifest-entry-properties package->manifest-entry)
+ (list p1 p2 p3 p4))))
+
(test-assertm "no collision"
;; Here we have an entry that is "lowered" (its 'item' field is a store file
;; name) and another entry (its 'item' field is a package) that is
--
2.17.0
guix-patches <at> gnu.org:bug#31442; Package guix-patches.
(Mon, 14 May 2018 08:27:04 GMT) Full text and rfc822 format available.Message #17 received at 31442 <at> debbugs.gnu.org (full text, mbox):
From: Ludovic Courtès <ludo <at> gnu.org> To: 31442 <at> debbugs.gnu.org Cc: Ludovic Courtès <ludo <at> gnu.org> Subject: [PATCH 5/5] DRAFT Add 'guix health'. Date: Mon, 14 May 2018 10:25:50 +0200
DRAFT: Needs doc and tests, plus the FIXME noted inside.
* guix/scripts/health.scm: New file.
* Makefile.am (MODULES): Add it.
* po/guix/POTFILES.in: Add it.
---
Makefile.am | 1 +
guix/scripts/health.scm | 158 ++++++++++++++++++++++++++++++++++++++++
po/guix/POTFILES.in | 1 +
3 files changed, 160 insertions(+)
create mode 100644 guix/scripts/health.scm
diff --git a/Makefile.am b/Makefile.am
index 38bd54cf4..870ff6a89 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -194,6 +194,7 @@ MODULES = \
guix/scripts/package.scm \
guix/scripts/gc.scm \
guix/scripts/hash.scm \
+ guix/scripts/health.scm \
guix/scripts/pack.scm \
guix/scripts/pull.scm \
guix/scripts/substitute.scm \
diff --git a/guix/scripts/health.scm b/guix/scripts/health.scm
new file mode 100644
index 000000000..a991fcbe3
--- /dev/null
+++ b/guix/scripts/health.scm
@@ -0,0 +1,158 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2018 Ludovic Courtès <ludo <at> gnu.org>
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.
+
+(define-module (guix scripts health)
+ #:use-module (guix ui)
+ #:use-module (guix scripts)
+ #:use-module (guix profiles)
+ #:use-module (guix packages)
+ #:use-module (guix cve)
+ #:use-module (guix utils)
+ #:use-module (gnu packages)
+ #:use-module (srfi srfi-1)
+ #:use-module (srfi srfi-37)
+ #:use-module (ice-9 match)
+ #:export (guix-health))
+
+
+;;;
+;;; Reporting CVEs.
+;;;
+
+(define (same-package-entries? entry1 entry2)
+ "Return true if ENTRY1 and ENTRY2 refer to the same package and version."
+ (and (string=? (manifest-entry-name entry1)
+ (manifest-entry-name entry2))
+ (string=? (manifest-entry-version entry1)
+ (manifest-entry-version entry2))))
+
+(define (manifest-entry-vulnerabilities entry lookup-vulnerabilities)
+ "Return the list of vulnerabilities for ENTRY. Call LOOKUP-VULNERABILITIES
+to determine the list of vulnerabilities for a package/version."
+ (let* ((name (manifest-entry-name entry))
+ (cpe-name (or (assoc-ref (manifest-entry-properties entry)
+ 'cpe-name)
+ name))
+ (version (manifest-entry-version entry))
+ (cpe-version (or (assoc-ref (manifest-entry-properties entry)
+ 'cpe-version)
+ version))
+ (fixed (or (assoc-ref (manifest-entry-properties entry)
+ 'fixed-vulnerabilities)
+ '())))
+ (remove (lambda (vuln)
+ (member (vulnerability-id vuln) fixed))
+ (lookup-vulnerabilities cpe-name cpe-version))))
+
+(define (check-profile-cve profile)
+ "Check and report the CVEs of packages in PROFILE."
+ (define lookup-vulnerabilities
+ (vulnerabilities->lookup-proc (current-vulnerabilities)))
+
+ (define (report-entry-vulnerabilities entry)
+ (let ((name (manifest-entry-name entry))
+ (version (manifest-entry-version entry)))
+ (match (manifest-entry-vulnerabilities entry lookup-vulnerabilities)
+ (()
+ #t)
+ ((vulns ...)
+ (warning (G_ "~a@~a may be vulnerable to~{ ~a~}~%")
+ name version (map vulnerability-id vulns))
+ (match (find-best-packages-by-name name #f)
+ ((package . _)
+ (let ((vulns* (lookup-vulnerabilities name
+ (package-version package))))
+ (match (lset-difference string=?
+ (map vulnerability-id vulns)
+ (map vulnerability-id vulns*))
+ (()
+ (warning (G_ "~a@~a is available but does not \
+fix any of these~%")
+ name (package-version package))
+ (display-hint (format #f (G_ "Run @command{guix pull} and
+then re-run @command{guix health} to see if fixes are available. If none are
+available, please consider submitting a patch for the package definition of
+'~a'.") name)))
+ (fixed
+ (warning (G_ "~a@~a is available and fixes~{ ~a~}, \
+consider ugprading~%")
+ name (package-version package) fixed)))))
+ (()
+ (warning (G_ "'~a' is unavailable and thus \
+cannot be upgraded~%")
+ name)))))))
+
+ (let* ((manifest (profile-manifest profile))
+ (entries (manifest-transitive-entries manifest)))
+ ;; FIXME: We don't report vulnerabilities in dependencies of the entries.
+ ;; We could check the references and infer the package name/version for
+ ;; each of them, but then we wouldn't know their CPE name nor whether they
+ ;; already contain patches fixing known vulnerabilities.
+ (for-each report-entry-vulnerabilities
+ (delete-duplicates entries same-package-entries?))))
+
+
+;;;
+;;; Command-line options.
+;;;
+
+(define (show-help)
+ (display (G_ "Usage: guix health [OPTIONS]
+Report on the vulnerabilities of packages in a profile.\n"))
+ (display (G_ "
+ -p, --profile=PROFILE use PROFILE instead of the user's default profile"))
+ (newline)
+ (display (G_ "
+ -h, --help display this help and exit"))
+ (display (G_ "
+ -V, --version display version information and exit"))
+ (newline)
+ (show-bug-report-information))
+
+(define %options
+ (list (option '(#\h "help") #f #f
+ (lambda args
+ (show-help)
+ (exit 0)))
+ (option '(#\V "version") #f #f
+ (lambda args
+ (show-version-and-exit "guix package")))
+
+ (option '(#\p "profile") #t #f
+ (lambda (opt name arg result)
+ (values (alist-cons 'profile (canonicalize-profile arg)
+ result)
+ #f)))))
+
+(define %default-options
+ ;; Alist of default option values.
+ '())
+
+
+;;;
+;;; Entry point.
+;;;
+
+(define (guix-health . args)
+ (with-error-handling
+ (let* ((opts (parse-command-line args %options (list %default-options)
+ #:build-options? #f))
+ (profile (or (and=> (assoc-ref opts 'profile)
+ user-friendly-profile)
+ %user-profile-directory)))
+ (check-profile-cve profile))))
diff --git a/po/guix/POTFILES.in b/po/guix/POTFILES.in
index d11f408d4..76fdbe13b 100644
--- a/po/guix/POTFILES.in
+++ b/po/guix/POTFILES.in
@@ -31,6 +31,7 @@ guix/scripts/challenge.scm
guix/scripts/copy.scm
guix/scripts/pack.scm
guix/scripts/weather.scm
+guix/scripts/health.scm
guix/gnu-maintenance.scm
guix/scripts/container.scm
guix/scripts/container/exec.scm
--
2.17.0
guix-patches <at> gnu.org:bug#31442; Package guix-patches.
(Mon, 14 May 2018 08:27:04 GMT) Full text and rfc822 format available.Message #20 received at 31442 <at> debbugs.gnu.org (full text, mbox):
From: Ludovic Courtès <ludo <at> gnu.org> To: 31442 <at> debbugs.gnu.org Cc: Ludovic Courtès <ludo <at> gnu.org> Subject: [PATCH 2/5] packages: Add 'package-patched-vulnerabilities'. Date: Mon, 14 May 2018 10:25:47 +0200
* guix/packages.scm (patch-file-name): New procedure.
(%vulnerability-regexp): New variable.
(package-patched-vulnerabilities): New procedure.
* guix/scripts/lint.scm (patch-file-name): Remove.
(check-vulnerabilities): Adjust to use
'package-patched-vulnerabilities'.
* tests/packages.scm ("package-patched-vulnerabilities"): New test.
---
guix/packages.scm | 28 ++++++++++++++++++++++++++++
guix/scripts/lint.scm | 23 ++++-------------------
tests/packages.scm | 15 +++++++++++++++
3 files changed, 47 insertions(+), 19 deletions(-)
diff --git a/guix/packages.scm b/guix/packages.scm
index e0ab72086..f536597ae 100644
--- a/guix/packages.scm
+++ b/guix/packages.scm
@@ -35,6 +35,7 @@
#:use-module (guix sets)
#:use-module (ice-9 match)
#:use-module (ice-9 vlist)
+ #:use-module (ice-9 regex)
#:use-module (srfi srfi-1)
#:use-module (srfi srfi-9 gnu)
#:use-module (srfi srfi-11)
@@ -106,6 +107,7 @@
package-cross-derivation
package-output
package-grafts
+ package-patched-vulnerabilities
package/inherit
transitive-input-references
@@ -394,6 +396,32 @@ DELIMITER (a string), you can customize what will appear between the name and
the version. By default, DELIMITER is \"@\"."
(string-append (package-name package) delimiter (package-version package)))
+(define (patch-file-name patch)
+ "Return the basename of PATCH's file name, or #f if the file name could not
+be determined."
+ (match patch
+ ((? string?)
+ (basename patch))
+ ((? origin?)
+ (and=> (origin-actual-file-name patch) basename))))
+
+(define %vulnerability-regexp
+ ;; Regexp matching a CVE identifier in patch file names.
+ (make-regexp "CVE-[0-9]{4}-[0-9]+"))
+
+(define (package-patched-vulnerabilities package)
+ "Return the list of patched vulnerabilities of PACKAGE as a list of CVE
+identifiers. The result is inferred from the file names of patches."
+ (define (patch-vulnerabilities patch)
+ (map (cut match:substring <> 0)
+ (list-matches %vulnerability-regexp patch)))
+
+ (let ((patches (filter-map patch-file-name
+ (or (and=> (package-source package)
+ origin-patches)
+ '()))))
+ (append-map patch-vulnerabilities patches)))
+
(define (%standard-patch-inputs)
(let* ((canonical (module-ref (resolve-interface '(gnu packages base))
'canonical-package))
diff --git a/guix/scripts/lint.scm b/guix/scripts/lint.scm
index cd802985d..e477bf0dd 100644
--- a/guix/scripts/lint.scm
+++ b/guix/scripts/lint.scm
@@ -1,7 +1,7 @@
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2014 Cyril Roelandt <tipecaml <at> gmail.com>
;;; Copyright © 2014, 2015 Eric Bavier <bavier <at> member.fsf.org>
-;;; Copyright © 2013, 2014, 2015, 2016, 2017 Ludovic Courtès <ludo <at> gnu.org>
+;;; Copyright © 2013, 2014, 2015, 2016, 2017, 2018 Ludovic Courtès <ludo <at> gnu.org>
;;; Copyright © 2015, 2016 Mathieu Lirzin <mthl <at> gnu.org>
;;; Copyright © 2016 Danny Milosavljevic <dannym+a <at> scratchpost.org>
;;; Copyright © 2016 Hartmut Goebel <h.goebel <at> crazy-compilers.com>
@@ -809,15 +809,6 @@ descriptions maintained upstream."
(emit-warning package (G_ "invalid license field")
'license))))
-(define (patch-file-name patch)
- "Return the basename of PATCH's file name, or #f if the file name could not
-be determined."
- (match patch
- ((? string?)
- (basename patch))
- ((? origin?)
- (and=> (origin-actual-file-name patch) basename))))
-
(define (call-with-networking-fail-safe message error-value proc)
"Call PROC catching any network-related errors. Upon a networking error,
display a message including MESSAGE and return ERROR-VALUE."
@@ -878,20 +869,14 @@ the NIST server non-fatal."
(()
#t)
((vulnerabilities ...)
- (let* ((patches (filter-map patch-file-name
- (or (and=> (package-source package)
- origin-patches)
- '())))
+ (let* ((patched (package-patched-vulnerabilities package))
(known-safe (or (assq-ref (package-properties package)
'lint-hidden-cve)
'()))
(unpatched (remove (lambda (vuln)
(let ((id (vulnerability-id vuln)))
- (or
- (find (cute string-contains
- <> id)
- patches)
- (member id known-safe))))
+ (or (member id patched)
+ (member id known-safe))))
vulnerabilities)))
(unless (null? unpatched)
(emit-warning package
diff --git a/tests/packages.scm b/tests/packages.scm
index 9e19c3992..642a3efa5 100644
--- a/tests/packages.scm
+++ b/tests/packages.scm
@@ -941,6 +941,21 @@
((("x" dep))
(eq? dep findutils)))))))))
+(test-equal "package-patched-vulnerabilities"
+ '(("CVE-2015-1234")
+ ("CVE-2016-1234" "CVE-2018-4567")
+ ())
+ (let ((p1 (dummy-package "pi"
+ (source (dummy-origin
+ (patches (list "/a/b/pi-CVE-2015-1234.patch"))))))
+ (p2 (dummy-package "pi"
+ (source (dummy-origin
+ (patches (list
+ "/a/b/pi-CVE-2016-1234-CVE-2018-4567.patch"))))))
+ (p3 (dummy-package "pi" (source (dummy-origin)))))
+ (map package-patched-vulnerabilities
+ (list p1 p2 p3))))
+
(test-eq "fold-packages" hello
(fold-packages (lambda (p r)
(if (string=? (package-name p) "hello")
--
2.17.0
ludo <at> gnu.org (Ludovic Courtès)
to control <at> debbugs.gnu.org.
(Mon, 14 May 2018 08:27:05 GMT) Full text and rfc822 format available.ludo <at> gnu.org (Ludovic Courtès)
to control <at> debbugs.gnu.org.
(Mon, 14 May 2018 08:27:05 GMT) Full text and rfc822 format available.guix-patches <at> gnu.org:bug#31442; Package guix-patches.
(Sat, 09 Jun 2018 10:19:01 GMT) Full text and rfc822 format available.Message #27 received at 31442 <at> debbugs.gnu.org (full text, mbox):
From: ludo <at> gnu.org (Ludovic Courtès) To: 31442 <at> debbugs.gnu.org Subject: Re: [bug#31442] [PATCH 0/5] 'guix health': a tool to report vulnerable packages Date: Sat, 09 Jun 2018 12:18:06 +0200
Hello, Ludovic Courtès <ludo <at> gnu.org> skribis: > profiles: Add '%current-profile', 'user-friendly-profile', & co. > packages: Add 'package-patched-vulnerabilities'. > profiles: Add 'properties' field to manifest entries. > profiles: Record fixed vulnerabilities as properties of entries. > DRAFT Add 'guix health'. I’ve just pushed the first three patches and the new ‘guix pull’ uses properties already. Ludo’.
guix-patches <at> gnu.org:bug#31442; Package guix-patches.
(Fri, 18 Sep 2020 22:45:02 GMT) Full text and rfc822 format available.Message #30 received at 31442 <at> debbugs.gnu.org (full text, mbox):
From: zimoun <zimon.toutoune <at> gmail.com> To: ludo <at> gnu.org (Ludovic Courtès) Cc: Ricardo Wurmus <rekado <at> elephly.net>, Mathieu Othacehe <othacehe <at> gnu.org>, 31444 <at> debbugs.gnu.org, 31442 <at> debbugs.gnu.org Subject: Re: [bug#31444] 'guix health': a tool to report vulnerable packages Date: Sat, 19 Sep 2020 00:43:59 +0200
Hi, Digging in old bugs with patches, hit this one. :-) On Mon, 14 May 2018 at 00:15, ludo <at> gnu.org (Ludovic Courtès) wrote: > On IRC davidl shared a shell script that checks the output of ‘guix lint > -c cve’ and uses that to determine vulnerable packages in a profile. > That reminds me of the plan for ‘guix health’ (a tool to do just that), > so I went ahead and tried to make it a reality at last. > > This ‘guix health’ reports information about “leaf” packages in a > profile, but not about their dependencies: Well, I do not know what was the idea at the time. :-) (The search http://logs.guix.gnu.org/guix/search?query=nick%3Adavidl does not list logs before 2019 for the nickname. Do I miss something?) And I do not know if the idea is to report only “leaf” packages. Well, instead to create another new command, I think it would be better to include the “leaf” packages to “guix graph” and then pipe to “guix lint”. Other said, “guix graph” should help to manipulate the graph of packages. I am not sure it fits the idea behind “guix health” but the patch #43477 allows to only output the nodes, for example. <http://issues.guix.gnu.org/issue/43477> Here an example, to verify the SWH health of one profile. (Note I choose the archival checker because it display stuff. :-)) --8<---------------cut here---------------start------------->8--- $ guix package -p ~/.config/guix/profiles/apps/apps -I | cut -f1 youtube-dl mb2md isync xournal ghostscript imagemagick mupdf $for pkg in \ > $(guix package -p ~/.config/guix/profiles/apps/apps -I | cut -f1 | xargs ./pre-inst-env guix graph -b plain); \ > do guix lint -c archival $pkg ; done gnu/packages/video.scm:2169:12: youtube-dl <at> 2020.09.14: source not archived on Software Heritage gnu/packages/video.scm:1412:12: ffmpeg <at> 4.3.1: source not archived on Software Heritage gnu/packages/autotools.scm:286:12: automake <at> 1.16.2: source not archived on Software Heritage guix lint: error: autoconf-wrapper: package not found for version 2.69 gnu/packages/perl.scm:89:12: perl <at> 5.30.2: source not archived on Software Heritage gnu/packages/guile.scm:141:11: guile <at> 2.0.14: source not archived on Software Heritage gnu/packages/ed.scm:32:12: ed <at> 1.16: source not archived on Software Heritage [...] gnu/packages/xorg.scm:5280:6: libxcb <at> 1.14: source not archived on Software Heritage guix lint: error: tzdata: package not found for version 2019c gnu/packages/python.scm:514:2: python-minimal <at> 3.8.2: source not archived on Software Heritage gnu/packages/xorg.scm:2140:6: xcb-proto <at> 1.14: source not archived on Software Heritage [...] gnu/packages/shells.scm:376:12: tcsh <at> 6.22.02: source not archived on Software Heritage gnu/packages/icu4c.scm:43:11: icu4c <at> 66.1: Software Heritage rate limit reached; try again later C-c --8<---------------cut here---------------end--------------->8--- Obviously, the for-loop should be avoided. But raising an error by “guix lint” breaks the stream. Well, that’s another story. :-) To summary, instead of “guix health”, I suggest to add “features“ to ‘guix graph’ (support manifest files, more facilities to manipulate/show the DAG). > The difficulty here is that we need to know a package’s CPE name before > we can check the CVE database, and we also need to know whether the > package already includes fixes for known CVEs. This patch set attaches > this information to manifest entries, so that ‘guix health’ can then > rely on it. Well, I am not sure to understand. Is it not somehow an issue of ‘guix lint -c cve’? > Fundamentally, that means we cannot reliably tell much about > dependencies: in cases where the CPE name differs from the Guix name, we > won’t have any match, and more generally, we cannot know what CVE are > patched in the package; we could infer part of this by looking at the > same-named package in the current Guix, but that’s hacky. > > I think that longer-term we probably need to attach this kind of > meta-data to packages themselves, by adding a bunch of files in each > package, say under PREFIX/guix. We could do that for search paths as > well. What is the status of this idea? > Should we satisfy ourselves with the current approach in the meantime? > Thoughts? > > Besides, support for properties in manifest entries seems useful to me, > so we may want to keep it regardless of whether we take ‘guix health’ > as-is. I am not sure that my email is relevant, but at least it will ping for ‘guix health’. :-) Cheers, simon
guix-patches <at> gnu.org:bug#31442; Package guix-patches.
(Fri, 25 Sep 2020 16:35:02 GMT) Full text and rfc822 format available.Message #33 received at 31442 <at> debbugs.gnu.org (full text, mbox):
From: Ludovic Courtès <ludo <at> gnu.org> To: zimoun <zimon.toutoune <at> gmail.com> Cc: Ricardo Wurmus <rekado <at> elephly.net>, Mathieu Othacehe <othacehe <at> gnu.org>, 31444 <at> debbugs.gnu.org, 31442 <at> debbugs.gnu.org Subject: Re: [bug#31444] 'guix health': a tool to report vulnerable packages Date: Fri, 25 Sep 2020 18:34:00 +0200
Hi! zimoun <zimon.toutoune <at> gmail.com> skribis: > Well, instead to create another new command, I think it would be better > to include the “leaf” packages to “guix graph” and then pipe to “guix > lint”. Other said, “guix graph” should help to manipulate the graph of > packages. I don’t think so. One reason is that ‘guix lint’ is really a generic tool for package developers that happens to include a ‘cve’ checker; apart from that, it’s not designed for CVE handling. More importantly, ‘guix health’ needs info not available in the output of ‘guix lint’: it needs the CPE name of each package in the graph, along with the list of known-fixed CVEs. >> Fundamentally, that means we cannot reliably tell much about >> dependencies: in cases where the CPE name differs from the Guix name, we >> won’t have any match, and more generally, we cannot know what CVE are >> patched in the package; we could infer part of this by looking at the >> same-named package in the current Guix, but that’s hacky. >> >> I think that longer-term we probably need to attach this kind of >> meta-data to packages themselves, by adding a bunch of files in each >> package, say under PREFIX/guix. We could do that for search paths as >> well. > > What is the status of this idea? The idea is still up in the air. :-) In the meantime, package metadata is added to manifest entries. Ludo’.
guix-patches <at> gnu.org:bug#31442; Package guix-patches.
(Fri, 21 Jul 2023 16:45:02 GMT) Full text and rfc822 format available.Message #36 received at 31442 <at> debbugs.gnu.org (full text, mbox):
From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> To: zimoun <zimon.toutoune <at> gmail.com> Cc: Ricardo Wurmus <rekado <at> elephly.net>, Mathieu Othacehe <othacehe <at> gnu.org>, Ludovic Courtès <ludo <at> gnu.org>, 31444 <at> debbugs.gnu.org, 31442 <at> debbugs.gnu.org Subject: Re: bug#31444: 'guix health': a tool to report vulnerable packages Date: Fri, 21 Jul 2023 12:44:11 -0400
Hi Simon, zimoun <zimon.toutoune <at> gmail.com> writes: > Hi, > > Digging in old bugs with patches, hit this one. :-) > > > On Mon, 14 May 2018 at 00:15, ludo <at> gnu.org (Ludovic Courtès) wrote: > >> On IRC davidl shared a shell script that checks the output of ‘guix lint >> -c cve’ and uses that to determine vulnerable packages in a profile. >> That reminds me of the plan for ‘guix health’ (a tool to do just that), >> so I went ahead and tried to make it a reality at last. >> >> This ‘guix health’ reports information about “leaf” packages in a >> profile, but not about their dependencies: > > Well, I do not know what was the idea at the time. :-) > (The search http://logs.guix.gnu.org/guix/search?query=nick%3Adavidl > does not list logs before 2019 for the nickname. Do I miss something?) > > And I do not know if the idea is to report only “leaf” packages. > > Well, instead to create another new command, I think it would be better > to include the “leaf” packages to “guix graph” and then pipe to “guix > lint”. Other said, “guix graph” should help to manipulate the graph of > packages. I like this idea to allow composing our already existing commands, the UNIX way. It'd be useful not just for this use case, but to better exploit the Guix command line API in general. > I am not sure it fits the idea behind “guix health” but the patch #43477 > allows to only output the nodes, for example. > > <http://issues.guix.gnu.org/issue/43477> > > > Here an example, to verify the SWH health of one profile. (Note I > choose the archival checker because it display stuff. :-)) > > $ guix package -p ~/.config/guix/profiles/apps/apps -I | cut -f1 > youtube-dl > mb2md > isync > xournal > ghostscript > imagemagick > mupdf > > $for pkg in \ >> $(guix package -p ~/.config/guix/profiles/apps/apps -I | cut -f1 | xargs ./pre-inst-env guix graph -b plain); \ >> do guix lint -c archival $pkg ; done > gnu/packages/video.scm:2169:12: youtube-dl <at> 2020.09.14: source not archived on Software Heritage > gnu/packages/video.scm:1412:12: ffmpeg <at> 4.3.1: source not archived on Software Heritage > gnu/packages/autotools.scm:286:12: automake <at> 1.16.2: source not archived on Software Heritage > guix lint: error: autoconf-wrapper: package not found for version 2.69 > gnu/packages/perl.scm:89:12: perl <at> 5.30.2: source not archived on Software Heritage > gnu/packages/guile.scm:141:11: guile <at> 2.0.14: source not archived on Software Heritage > gnu/packages/ed.scm:32:12: ed <at> 1.16: source not archived on Software Heritage > > [...] > > gnu/packages/xorg.scm:5280:6: libxcb <at> 1.14: source not archived on Software Heritage > guix lint: error: tzdata: package not found for version 2019c > gnu/packages/python.scm:514:2: python-minimal <at> 3.8.2: source not archived on Software Heritage > gnu/packages/xorg.scm:2140:6: xcb-proto <at> 1.14: source not archived on Software Heritage > > [...] > > gnu/packages/shells.scm:376:12: tcsh <at> 6.22.02: source not archived on Software Heritage > gnu/packages/icu4c.scm:43:11: icu4c <at> 66.1: Software Heritage rate limit reached; try again later > C-c > > Obviously, the for-loop should be avoided. But raising an error by > “guix lint” breaks the stream. Well, that’s another story. :-) > > > To summary, instead of “guix health”, I suggest to add “features“ to > ‘guix graph’ (support manifest files, more facilities to manipulate/show > the DAG). I like this idea too. > >> The difficulty here is that we need to know a package’s CPE name before >> we can check the CVE database, and we also need to know whether the >> package already includes fixes for known CVEs. This patch set attaches >> this information to manifest entries, so that ‘guix health’ can then >> rely on it. > > Well, I am not sure to understand. Is it not somehow an issue of ‘guix > lint -c cve’? This is my understand as well. Ludo, if your proposition has gone stale and you don't plan to work on it anytime soon, feel free to close it. -- Thanks, Maxim
guix-patches <at> gnu.org:bug#31442; Package guix-patches.
(Fri, 08 Sep 2023 16:27:01 GMT) Full text and rfc822 format available.Message #39 received at 31442 <at> debbugs.gnu.org (full text, mbox):
From: Ludovic Courtès <ludo <at> gnu.org> To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> Cc: Ricardo Wurmus <rekado <at> elephly.net>, Mathieu Othacehe <othacehe <at> gnu.org>, 31444 <at> debbugs.gnu.org, 31442 <at> debbugs.gnu.org, zimoun <zimon.toutoune <at> gmail.com> Subject: Re: bug#31444: 'guix health': a tool to report vulnerable packages Date: Fri, 08 Sep 2023 18:25:53 +0200
Hello! Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis: > zimoun <zimon.toutoune <at> gmail.com> writes: [...] >>> This ‘guix health’ reports information about “leaf” packages in a >>> profile, but not about their dependencies: >> >> Well, I do not know what was the idea at the time. :-) >> (The search http://logs.guix.gnu.org/guix/search?query=nick%3Adavidl >> does not list logs before 2019 for the nickname. Do I miss something?) >> >> And I do not know if the idea is to report only “leaf” packages. Reporting only leaf packages was a limitation, not a goal. The limitation stemmed from the fact that, to determine whether a package is vulnerable, we need to (1) map its store file name to its package name, and (2) map its package name to its CPE name. We can do #1 via manifests, but only for leaf packages (because there’s no metadata available for other store items). >> Well, instead to create another new command, I think it would be better >> to include the “leaf” packages to “guix graph” and then pipe to “guix >> lint”. Other said, “guix graph” should help to manipulate the graph of >> packages. > > I like this idea to allow composing our already existing commands, the > UNIX way. It'd be useful not just for this use case, but to better > exploit the Guix command line API in general. I’m all for composition, who wouldn’t? :-) I think composition works best within a rich language; sending text over pipes is often too limited. [...] > Ludo, if your proposition has gone stale and you don't plan to work on > it anytime soon, feel free to close it. There’s been progress since I posted this patch: manifests now include provenance info, which means we can map profiles back to package definitions! So we could make a proper ‘guix health’ at this stage. I’d like to say I’ll work on it soon but reality is that I’m a bit swamped. Anyhow, I think it remains a useful tool, and whether it’s me or someone else working on it, we should probably aim for it at some point. Thanks, Ludo’.
guix-patches <at> gnu.org:bug#31442; Package guix-patches.
(Sat, 09 Sep 2023 22:15:01 GMT) Full text and rfc822 format available.Message #42 received at 31442 <at> debbugs.gnu.org (full text, mbox):
From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> To: Ludovic Courtès <ludo <at> gnu.org> Cc: Ricardo Wurmus <rekado <at> elephly.net>, Mathieu Othacehe <othacehe <at> gnu.org>, 31444 <at> debbugs.gnu.org, 31442 <at> debbugs.gnu.org, zimoun <zimon.toutoune <at> gmail.com> Subject: Re: bug#31444: 'guix health': a tool to report vulnerable packages Date: Sat, 09 Sep 2023 18:14:13 -0400
Hi Ludovic, Ludovic Courtès <ludo <at> gnu.org> writes: [...] > Reporting only leaf packages was a limitation, not a goal. The > limitation stemmed from the fact that, to determine whether a package is > vulnerable, we need to (1) map its store file name to its package name, > and (2) map its package name to its CPE name. > > We can do #1 via manifests, but only for leaf packages (because there’s > no metadata available for other store items). [...] > There’s been progress since I posted this patch: manifests now include > provenance info, which means we can map profiles back to package > definitions! So we could make a proper ‘guix health’ at this stage. > > I’d like to say I’ll work on it soon but reality is that I’m a bit > swamped. Anyhow, I think it remains a useful tool, and whether it’s me > or someone else working on it, we should probably aim for it at some > point. Thanks for the update. It's OK to keep it here if all that is missing is some extra work to push it to the finish line, so let's keep this one open. On a related note sometimes we have WIP kind of work that stays on our tracker with deeper questions / problems to solve, and I don't think it's fair for our reviewers to have these linger on for years on the tracker (they take a lot of time to get familiar with, and would then require quit more investment to be completed, sometimes with the original submitter no longer active in the discussion) -- I think for these situations it's fair to close it. An interested person can hopefully find these in the archives and resume work on it if they are so inclined. -- Thanks, Maxim
guix-patches <at> gnu.org:bug#31442; Package guix-patches.
(Wed, 13 Sep 2023 20:00:02 GMT) Full text and rfc822 format available.Message #45 received at 31442 <at> debbugs.gnu.org (full text, mbox):
From: Ludovic Courtès <ludo <at> gnu.org> To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> Cc: Ricardo Wurmus <rekado <at> elephly.net>, Mathieu Othacehe <othacehe <at> gnu.org>, 31444 <at> debbugs.gnu.org, 31442 <at> debbugs.gnu.org, zimoun <zimon.toutoune <at> gmail.com> Subject: Re: bug#31444: 'guix health': a tool to report vulnerable packages Date: Wed, 13 Sep 2023 21:58:45 +0200
Hi, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis: > On a related note sometimes we have WIP kind of work that stays on our > tracker with deeper questions / problems to solve, and I don't think > it's fair for our reviewers to have these linger on for years on the > tracker (they take a lot of time to get familiar with, and would then > require quit more investment to be completed, sometimes with the > original submitter no longer active in the discussion) -- I think for > these situations it's fair to close it. An interested person can > hopefully find these in the archives and resume work on it if they are > so inclined. Yes, I share this sentiment, especially with my reviewer hat on (I guess I had my passerby hat on when I sent this patch, or most likely I thought it’d cross the finish line Real Soon; I agree it’s also fine if we close it). Ludo’.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.