[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: zimoun
Subject: [bug#31442] [bug#31444] 'guix health': a tool to report vulnerable packages
Date: Sat, 19 Sep 2020 00:43:59 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)


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

On Mon, 14 May 2018 at 00:15, (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
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

I am not sure it fits the idea behind “guix health” but the patch #43477
allows to only output the nodes, for example.


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

$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 
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 
gnu/packages/guile.scm:141:11: guile@2.0.14: source not archived on Software 
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 
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 


gnu/packages/shells.scm:376:12: tcsh@6.22.02: source not archived on Software 
gnu/packages/icu4c.scm:43:11: icu4c@66.1: Software Heritage rate limit reached; 
try again later
--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’. :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]