#31444 'guix health': a tool to report vulnerable packages

Message #22 received at 31444@debbugs.gnu.org (full text, mbox, reply):

Received: (at 31444) by debbugs.gnu.org; 18 Sep 2020 22:44:13 +0000
From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 18 18:44:13 2020
Received: from localhost ([127.0.0.1]:45286 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces@debbugs.gnu.org>)
	id 1kJP6v-00010T-2H
	for submit@debbugs.gnu.org; Fri, 18 Sep 2020 18:44:13 -0400
Received: from mail-wr1-f46.google.com ([209.85.221.46]:39503)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <zimon.toutoune@gmail.com>)
 id 1kJP6t-0000zv-CB; Fri, 18 Sep 2020 18:44:07 -0400
Received: by mail-wr1-f46.google.com with SMTP id a17so7058266wrn.6;
 Fri, 18 Sep 2020 15:44:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version:content-transfer-encoding;
 bh=SvzKX7GV+wwO4HBRnj4hJaJW9oMNDHZJFLnlYR8wcjE=;
 b=VTSDLCBjQfx3+m186rFL3Bbq5WWxFv33589uNxz+W2SpRQQvyRu2ewpXWQZjpqeLMl
 xImBWtqu5qoBIvd6X2HJ7hxB6OwFM166meWRJmekSozDbxHD5+7DDMlpiFMQJ4y8t6yo
 8Dd0CrMdMxUeCr4PXz/RZi4fP63uo0RPJQjh/kSexjlnDdj5nH3sbND6BUkEc4KoV+a1
 QTO1P+lmP9GK+Mr4NW9WK1mJz26pW93Q3vXHwklx/9fADWCs7Mnm4TH00js9t1EYwBtk
 hqKBYkgXlBg5V33P+AaWm6KPczO0q6dd/mnXosMsjgwbezq0dO6oc4FaQy4aMPaaftAH
 xqHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version:content-transfer-encoding;
 bh=SvzKX7GV+wwO4HBRnj4hJaJW9oMNDHZJFLnlYR8wcjE=;
 b=N+FZdNiomMr489O6/MNSRbnFw3aitY9hdgqxyuhbudYHT6fFnS6k50zsO45aIlwy3L
 r3xUl7MJycccdw6tm//gREQsfR2eraHltDpFloLtxiE129c7w/yhhNwS8hAYUx9xOxKy
 Uet/ycAEft5WTwNYirsZGbaNrW1jXJxERT0/hkD02WEe/xpQQva+nUhrxwfr73iITF1u
 elMB7+RarA7fo099xw/T1SRovRvWfaP0vtkRbPwcc8+W+o0cyasi8Fz6x8G9y4/scr0y
 7w7iKVKyNbQB/tOUZJZ//obkINV6OxdmMH8vPPG8ounTXUeuQummOVDfvbx2Cm6wclbw
 0gCw==
X-Gm-Message-State: AOAM5313UvgPkFiu9Zy2Tp9DOuWt5FovHPhfLrXsQVT8bNFhkN0Fe5Ag
 B6tQeQxWe0BTLBitV/Sbsdc=
X-Google-Smtp-Source: ABdhPJy/VquQB3XuMOTsfnrKeELsp227GwXjZyAoqwBJAlP0cNeQ4rIH7LznHOntXovW/KJO4rNcFA==
X-Received: by 2002:adf:e601:: with SMTP id p1mr42928256wrm.172.1600469041130; 
 Fri, 18 Sep 2020 15:44:01 -0700 (PDT)
Received: from lili ([2a01:e0a:59b:9120:65d2:2476:f637:db1e])
 by smtp.gmail.com with ESMTPSA id q13sm8482475wra.93.2020.09.18.15.44.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 18 Sep 2020 15:44:00 -0700 (PDT)
From: zimoun <zimon.toutoune@gmail.com>
To: ludo@gnu.org (Ludovic Courtès)
Subject: Re: [bug#31444] 'guix health': a tool to report vulnerable packages
References: <87fu2vjj76.fsf@gnu.org>
Date: Sat, 19 Sep 2020 00:43:59 +0200
In-Reply-To: <87fu2vjj76.fsf@gnu.org> ("Ludovic Courtès"'s message of "Mon, 14 May 2018 00:15:41 +0200")
Message-ID: <864knuk8nk.fsf@gmail.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 31444
Cc: Ricardo Wurmus <rekado@elephly.net>, Mathieu Othacehe <othacehe@gnu.org>,
 31444@debbugs.gnu.org, 31442@debbugs.gnu.org
X-BeenThere: debbugs-submit@debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request@debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit@debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request@debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request@debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces@debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

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

Send a report that this bug log contains spam.