[caveat: no expertise in package / distro security, end user only. i'm interested letting a user answer the question: how interested is distro X in security?]
assuming that lack of doc on wiki & ~empty placeholder MER#161 mean there is no proposed CVE-tracking infrastructure for mer, here are some options in need of expert comment: (1) http://www.enricozini.org/2011/debian/distromatch/ http://wiki.debian.org/DEHS http://distrowatch.com/packages.php oswatershed.org maybe suited to tracking upstream package version numbers (MER#97) by tracking pkgs in other distros, but not for tracking package CVE's directly. (2) follow meego procedure? (common to desktop vendors also) (a) CVE -> (b) meego bug report -> (c) updated packages [changelog references CVE id (mostly); sometimes only references the bug id (not so good)] -> (d) meego security advisory currently mer has placeholders for none of this? (but maybe mer infrastructure component IT Private is a placeholder for (secure) bug report (b) or mer-SA (d))? meego had mailing list: http://lists.meego.com/listinfo/meego-security with mails w/ subject like: [MeeGo-security] [MeeGo-SA-10:21.libpng] Buffer overflow in libpng might allow a rbitrary code w/ content that referenced: MeeGo BID: 3855 CVE: CVE-2010-1205 etc. the bug BID, http://bugs.meego.com/show_bug.cgi?id=3855 had title like CVE-2010-1205 [libpng] libpng row data buffer overflow with bugzilla tags like: Product: Security URL: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-1205 with content containing the complete CVE text. and the fixed package has a changelog entry like: <changelog author="Bin Gao <[email protected]> - 1.2.44" date="1278331200">- Update to 1.2.44 which includes CVE fix for CVE-2010-1205 and CVE-2010-2249 so, it is/was relatively easy to search bugzilla or changelogs, etc. for CVE's that had been treated. ----------- if (2) is suitable, at least initially: i hacked some stuff together following what is done at: https://www.redhat.com/security/data/metrics and using repodata. (equivalent could be done using gerrit/git contents, probably) (a) for each mer release, define a unique CPE, e.g., i made up these entries based on repodata: Release id Common Product Enumeration Deprecated? 0.20120120.1 cpe:/o:merproject:mer:0.20120120.1 True 0.20120209.1 cpe:/o:merproject:mer:0.20120209.1 True 0.20120315.1 cpe:/o:merproject:mer:0.20120315.1 False this is trivial. ('deprecated' -> end-of-life -> only care about current release? or try to maintain multiple releases (more work)?) (b) for each release, generate a 'package' or 'product' list, e.g., cpe:/o:merproject:mer:0.20120315.1/python this is mostly trivial. (c) map each package (main package; sub-packages are implicitly treated) to a 'standard' CPE. common external packages already have well-known CPE's, e.g., python cpe:/a:python:python python:2.6 cpe:/a:python:python:2.6 python:2.6.5 cpe:/a:python:python:2.6.5 coreutils cpe:/a:gnu:coreutils new, uncommon or internal packages likely don't have CPE's, but it is in the best interest of CVE tracking to have them assigned. using the official-cpe-dictionary_v2.2.xml, i found about 30 cpe hits for mer main packages (~348 main packages, 515 sub-packages). turns out that the official dictionary doesn't have all CPE's that occur in CVE db. i'll have to redo the list using the CVE db. in any case, only ~10% of main mer packages can be currently tracked in CVE. whether it is worth maintaining this proposed infrastructure for only ~10% of packages is tbd. an alternative may be to just pay attention to upstream vendor rss feeds (if any). note also that the CPE/CVE db's have zero mention of moblin/maemo/meego/tizen, etc., but they do contain references to a few android apps; so it is not clear that mobile distro's have bought in (or caught up) to this approach. it is well entrenched in the linux / mac / windows desktop world. (d) use the well-known CPE to search the CVE database (~xml file, few to many MB in size). the online search is at http://web.nvd.nist.gov/view/vuln/search the CVE db is updated hourly or at least daily. there is a timelag (a few days?) between when the vendors release fixes and when the mentioned CVE's show up in the CVE db. this is maybe the window of opportunity. for reference, RHEL6 claims 98% of critical flaws are fixed in 1 day. to bootstrap mer, the historical data will have to be searched once to find / clarify the status of all related / inherited CVE's. subsequently, only the CVE updates (rss feed available) need be searched regularly for new vulnerabilities. this is ~trivially automated for well-known CPE's, even to the point of generating a new bug report; for non-well-known cpe's, it could probably just flag potential CPE's (via keywords) for review by the package maintainer, ranking them by the CVE CVSS severity. (e) a CPE match in the CVE db is also a good indication that a new (security fix, at least) version of the package/product is available upstream (re: MER#97). in the tentative list of CPE's i built for major mer packages, there are currently exposed CVE's, some recent, others not so. i hesitate to put the full list of older CVE's or packages in the general mailing list, or even on the open bugzilla, though this info is publically available. should i submit the list (1 CVE (per package?) per bug?) to the IT Private component in bugzilla? https://bugs.merproject.org/page.cgi?id=bug-writing.html doesn't describe process
