all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Leo Famulari <leo@famulari.name>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: Dealing with CVEs that apply to unspecified package versions
Date: Fri, 10 Mar 2017 23:05:34 -0500	[thread overview]
Message-ID: <20170311040534.GA31017@jasmine> (raw)
In-Reply-To: <877f4284un.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 1781 bytes --]

On Mon, Mar 06, 2017 at 10:36:48PM +0100, Ludovic Courtès wrote:
> Unfortunately, there’s no way to know whether such CVEs are actually
> fixed at a specific package version or not, and they’re not uncommon.
> Consequently, ‘guix lint -c cve’ would now report old CVEs that possibly
> no longer apply to our package versions.

I didn't notice any change in what the CVE checker reports after
applying the diff. Did I miss a step?

> In the patch, I added the ability to specify a ‘patched-vulnerabilities’
> property to work around that (with Coreutils as an example).  The
> downside is that we’d have to maintain these lists by ourselves, which
> is not great, but might still be better than the status quo.

Overall, I think it's better for the CVE checker to omit some CVEs than
to show a large number of false positives. Otherwise people may not pay
attention to it at all. And the CVE checker will never be authoritative;
Guix developers have to look for security advisories from a wide variety
of sources.

I wonder if we could maintain the set 'patched-vulnerabilities' fields
satisfactorily.

Changing the subject, this implementation of 'patched-vulnerabilities'
doesn't preserve the valuable information of how we know the
vulnerability was fixed (patch?  update? only applicable to non-GNU
platforms? et cetera).

If we were to start collecting and curating this information, we should
try to preserve it and make it useful to the other distros.

In that case, we could instead update the CVE database through MITRE's
new CVE form, which recently became the only way to get new CVEs from
MITRE:

https://cveform.mitre.org

I think the goal is to reduce the friction of requesting and amending
CVEs. Let's try it :)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2017-03-11  4:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-06 21:36 Dealing with CVEs that apply to unspecified package versions Ludovic Courtès
2017-03-11  4:05 ` Leo Famulari [this message]
2017-03-11 11:09   ` Ludovic Courtès
2017-03-16 10:07     ` 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

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

  git send-email \
    --in-reply-to=20170311040534.GA31017@jasmine \
    --to=leo@famulari.name \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.