[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150323042006.GA27422@openwall.com>
Date: Mon, 23 Mar 2015 07:20:06 +0300
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE for Kali Linux
On Sun, Mar 22, 2015 at 10:09:51PM -0600, Kurt Seifried wrote:
> My understanding was for software that downloads updates or other
> executable components over HTTP instead of HTTPS, AND there is no other
> protection (e.g. signed RPMs), so in effect there is nothing to protect
> it, then it gets a CVE since the user is essentially up the creek at
> that point.
If CVE goes this far, then I recommend that we don't include http vs.
https into this equation. Simply require signatures. "No signature for
software? Here's your CVE." This simple.
A problem here is that these are operations and not software issues, so
assigning CVEs for them would be inconsistent with and useless for the
usual purpose of CVEs (tracking of fixes in distros and deployments),
and with CVEs being assigned to specific software versions (a signature
will generally be added without releasing a new version).
I think these issues should be tracked separately, not via CVE. I agree
that tracking lack of software signatures, and encouraging change, is a
good idea.
Alexander
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
