GNU bug report logs - #31444
'guix health': a tool to report vulnerable packages

Previous Next

Full log

Message #28 received at 31444 <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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.