[bug#31442] [bug#31444] 'guix health': a tool to report vulnerable packages

[zimoun]

Hi,

Digging in old bugs with patches, hit this one. :-)


On Mon, 14 May 2018 at 00:15, ludo@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@2020.09.14: source not archived on 
Software Heritage
gnu/packages/video.scm:1412:12: ffmpeg@4.3.1: source not archived on Software 
Heritage
gnu/packages/autotools.scm:286:12: automake@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@5.30.2: source not archived on Software 
Heritage
gnu/packages/guile.scm:141:11: guile@2.0.14: source not archived on Software 
Heritage
gnu/packages/ed.scm:32:12: ed@1.16: source not archived on Software Heritage

[...]

gnu/packages/xorg.scm:5280:6: libxcb@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@3.8.2: source not archived on 
Software Heritage
gnu/packages/xorg.scm:2140:6: xcb-proto@1.14: source not archived on Software 
Heritage

[...]

gnu/packages/shells.scm:376:12: tcsh@6.22.02: source not archived on Software 
Heritage
gnu/packages/icu4c.scm:43:11: icu4c@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