On Tue, Mar 22, 2016 at 10:06 PM, Antoine Beaupré wrote: > Well, the friction is one thing, but we need to adopt *one* system for > the future, if CVEs are going the wayside (or even as a complementary > approach).
I agree with this post from oss-security: https://marc.info/?l=oss-security&m=145764213513572&w=2 Fracturing of the security identifier space is inevitable and already happening to some extent even before the CVE policy changes and before OVE/OVI/DWF/etc started; many projects have their own identifiers and some of those don't use CVEs (notably node-security and drupal AFAICS). Here are some examples of project-specific identifiers: https://anonscm.debian.org/viewvc/secure-testing/check-external/sources.ini?view=markup I think Debian needs to go towards the approach of VRDX-SIG and do identifier cross-referencing instead of settling on *one* system for referring to security vulnerabilities. Internally, we would continue to use CVEs and CVE-2016-XXXX for issues without CVEs and then map all the external identifiers onto those. > DWF seems interesting because it incorporates CVE IDs > directly and it also allocates CVE ranges to various projects. > Debian could be one of those: > > https://github.com/distributedweaknessfiling/DNA-Registry/blob/master/DNA-Registry.csv > > ... and manage its own allocations. ETOOMUCHGITHUB :) > I am not sure I like the CSVs, however... and it doesn't seem to have > much adoption yet: > > https://github.com/distributedweaknessfiling/DWF-Database/blob/master/DWF-Database-2016.csv More available here: https://github.com/distributedweaknessfiling/DWF-Database/blob/master/DWF-Database-2015.csv Wow, both of those really aren't useful at all; no external references or actionable useful information. Either way we need to support it since it is already being used. I have a local branch of the security tracker that has a data/DWF/list file containing the following. Ultimately though, I think that is the wrong approach. Instead, data/CVE/list should continue to contain all the data and we just add {DWF-2016-89999 DRUPAL-SA-37134} to the beginning of the entry like we do for DSA/DLA. Then the tracker needs to grow support for extra security issue identifiers and we need a script reading sources.ini and automatically pulling down each kind of identifier and adding it to data/CVE/list, as we do for CVEs themselves. https://wiki.debian.org/SummerOfCode2015/ProjectProposals/SecurityTrackerCheckExternal https://anonscm.debian.org/viewvc/secure-testing/check-external/sources.ini?view=markup DWF-2016-89000 Fedora captcha system weakness NOT-FOR-US NOTE: https://patrick.uiterwijk.org/2016/03/09/fedora-spam-dwf-2016-89000/ DWF-2016-89001 [Shotwell does not validate TLS certificates] - shotwell 0.22.0-3 (bug #807110) NOTE: https://bugzilla.gnome.org/show_bug.cgi?id=754488 > Centralisation certainly doesn't scale here... I think using debbugs or similar for CVE numbers could easily scale, if a few features were added to it, but I doubt that will happen. https://marc.info/?l=oss-security&m=145766818820035&w=2 -- bye, pabs https://wiki.debian.org/PaulWise
