[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#31442] [bug#31444] 'guix health': a tool to report vulnerable packa
[bug#31442] [bug#31444] 'guix health': a tool to report vulnerable packages
Sat, 19 Sep 2020 00:43:59 +0200
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, email@example.com (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
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. :-))
$ 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: firstname.lastname@example.org: source not archived on
gnu/packages/video.scm:1412:12: email@example.com: source not archived on Software
gnu/packages/autotools.scm:286:12: firstname.lastname@example.org: source not archived on
guix lint: error: autoconf-wrapper: package not found for version 2.69
gnu/packages/perl.scm:89:12: email@example.com: source not archived on Software
gnu/packages/guile.scm:141:11: firstname.lastname@example.org: source not archived on Software
gnu/packages/ed.scm:32:12: email@example.com: source not archived on Software Heritage
gnu/packages/xorg.scm:5280:6: firstname.lastname@example.org: source not archived on Software
guix lint: error: tzdata: package not found for version 2019c
gnu/packages/python.scm:514:2: email@example.com: source not archived on
gnu/packages/xorg.scm:2140:6: firstname.lastname@example.org: source not archived on Software
gnu/packages/shells.scm:376:12: email@example.com: source not archived on Software
gnu/packages/icu4c.scm:43:11: firstname.lastname@example.org: Software Heritage rate limit reached;
try again later
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 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
What is the status of this idea?
> Should we satisfy ourselves with the current approach in the meantime?
> 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’
I am not sure that my email is relevant, but at least it will ping for
‘guix health’. :-)
- [bug#31442] [bug#31444] 'guix health': a tool to report vulnerable packages,