From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60114) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fIGfm-0003yq-OM for guix-patches@gnu.org; Mon, 14 May 2018 12:50:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fIGfi-0001eQ-5h for guix-patches@gnu.org; Mon, 14 May 2018 12:50:06 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:54951) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fIGfi-0001e7-1H for guix-patches@gnu.org; Mon, 14 May 2018 12:50:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fIGfh-0000Ga-MU for guix-patches@gnu.org; Mon, 14 May 2018 12:50:01 -0400 Subject: [bug#31444] 'guix health': a tool to report vulnerable packages Resent-Message-ID: Date: Mon, 14 May 2018 16:49:41 +0000 From: Nils Gillmann Message-ID: <20180514164941.kjokoakkooajpunx@abyayala> References: <87fu2vjj76.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87fu2vjj76.fsf@gnu.org> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 31444@debbugs.gnu.org Ludovic Courtès transcribed 3.4K bytes: > Hello Guix! > > 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: Did you intend to attach a patch to one of the 3 or 4 messages that made it to the bugtracker? I've checked when you've sent the message and today and saw no patches. I'm interested in the code, the general idea sounds good. > --8<---------------cut here---------------start------------->8--- > $ ./pre-inst-env guix health -p /run/current-system/profile/ > guix health: warning: util-linux@2.31.1 may be vulnerable to CVE-2018-7738 > guix health: warning: util-linux@2.31.1 is available but does not fix any of these > hint: Run `guix pull' and then re-run `guix health' to see if fixes are available. If > none are available, please consider submitting a patch for the package definition of > 'util-linux'. > > > guix health: warning: shadow@4.5 may be vulnerable to CVE-2018-7169 > guix health: warning: shadow@4.6 is available and fixes CVE-2018-7169, consider ugprading > guix health: warning: tar@1.29 may be vulnerable to CVE-2016-6321 > guix health: warning: tar@1.29 is available but does not fix any of these > hint: Run `guix pull' and then re-run `guix health' to see if fixes are available. If > none are available, please consider submitting a patch for the package definition of > 'tar'. > --8<---------------cut here---------------end--------------->8--- > > 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. > > 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. If you mean with metadata what I understand: I've started playing with this idea a while back. It would be good to attach more information to the package, mentioned in the past was "support the developers" links (not everyone publishes this on their website). Personally I'm going to make use of the "maintainer" function for packages, so people know where (hopefully relatively) exactly the package came from. Anyways, I have some other package related experiments.. Did you have anything else in mind, other than search-paths and CVE information? > 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. > > Ludo’. > > Ludovic Courtès (5): > profiles: Add '%current-profile', 'user-friendly-profile', & co. > packages: Add 'package-patched-vulnerabilities'. > profiles: Add 'properties' field to manifest entries. > profiles: Record fixed vulnerabilities as properties of entries. > DRAFT Add 'guix health'. > > Makefile.am | 1 + > guix/packages.scm | 28 +++++++ > guix/profiles.scm | 91 ++++++++++++++++++++-- > guix/scripts/health.scm | 158 +++++++++++++++++++++++++++++++++++++++ > guix/scripts/lint.scm | 23 +----- > guix/scripts/package.scm | 40 ---------- > po/guix/POTFILES.in | 1 + > tests/packages.scm | 15 ++++ > tests/profiles.scm | 22 ++++++ > 9 files changed, 312 insertions(+), 67 deletions(-) > create mode 100644 guix/scripts/health.scm > > -- > 2.17.0 > > >