unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: zimoun <zimon.toutoune@gmail.com>
Cc: "Ricardo Wurmus" <rekado@elephly.net>,
	"Mathieu Othacehe" <othacehe@gnu.org>,
	"Ludovic Courtès" <ludo@gnu.org>,
	31444@debbugs.gnu.org, 31442@debbugs.gnu.org
Subject: [bug#31444] 'guix health': a tool to report vulnerable packages
Date: Fri, 21 Jul 2023 12:44:11 -0400	[thread overview]
Message-ID: <87o7k5i59g.fsf_-_@gmail.com> (raw)
In-Reply-To: <864knuk8nk.fsf@gmail.com> (zimoun's message of "Sat, 19 Sep 2020 00:43:59 +0200")

Hi Simon,

zimoun <zimon.toutoune@gmail.com> writes:

> 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 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@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
>
> 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




  parent reply	other threads:[~2023-07-21 16:45 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-13 22:15 [bug#31444] 'guix health': a tool to report vulnerable packages Ludovic Courtès
2018-05-14  8:06 ` Martin Castillo
2018-05-14  9:07   ` Ludovic Courtès
2018-05-14 16:49 ` Nils Gillmann
2018-05-15  7:24   ` Ludovic Courtès
2020-09-18 22:43 ` zimoun
2020-09-25 16:34   ` Ludovic Courtès
2023-07-21 16:44   ` Maxim Cournoyer [this message]
2023-09-08 16:25     ` Ludovic Courtès
2023-09-09 22:14       ` Maxim Cournoyer
2023-09-13 19:58         ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o7k5i59g.fsf_-_@gmail.com \
    --to=maxim.cournoyer@gmail.com \
    --cc=31442@debbugs.gnu.org \
    --cc=31444@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    --cc=othacehe@gnu.org \
    --cc=rekado@elephly.net \
    --cc=zimon.toutoune@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).