(address . guix-patches@gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)
20180513211546.10858-1-ludo@gnu.org
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:
Toggle snippet (17 lines)
$ ./pre-inst-env guix health -p /run/current-system/profile/
guix health: warning: util-linux@2.31.1 may be vulnerable to CVE-2018-7738
guix health: warning: util-linux@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@4.5 may be vulnerable to CVE-2018-7169
guix health: warning: shadow@4.6 is available and fixes CVE-2018-7169, consider ugprading
guix health: warning: tar@1.29 may be vulnerable to CVE-2016-6321
guix health: warning: tar@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'.
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