8619 2015-10-30 07:13:24 +0000 libarchive has open CVEs: CVE-2015-2304, CVE-2013-0211 2015-11-03 18:36:09 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core unspecified x86 Multiple RESOLVED OBSOLETE Undecided normal --- 1 elena.reshetova ross.burton meta.mr.watcher meta.watcher --- --- No (bug/feature does not impact docs) oldest_to_newest 56031 0 elena.reshetova 2015-10-30 07:13:24 +0000 https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-2304 https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0211 56081 1 ross.burton 2015-11-02 11:42:33 +0000 2013-0211 is in git already: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-extended/libarchive/libarchive/libarchive-CVE-2013-0211.patch 56082 2 ross.burton 2015-11-02 11:46:18 +0000 Also 2015-2304 is fixed in "0001-Add-ARCHIVE_EXTRACT_SECURE_NOABSOLUTEPATHS-option.patch". I get why the 2015-2304 wasn't detected by whatever CVE scanning tool you are using, but I do wonder why 2012-0211 wasn't detected as it has the CVE name in the filename. 56083 3 elena.reshetova 2015-11-02 11:54:05 +0000 That's a good question. I will investigate why it wasn't detected. Now we have a first real case, so it helps. 56125 4 elena.reshetova 2015-11-03 08:46:02 +0000 Actually I checked this one and the fault is not on the tool side but on the reporter side (me :)). Tool correctly detected that there are two CVEs, but marked one as patched (2013 one), but since the difference in cve-check.tool reporting is only comma vs. space, I didn't notice it and reported both. Would it be possible to rename the patch for 2015 CVE also to somehow reflect that it fixes cve? 56147 5 ross.burton 2015-11-03 16:23:18 +0000 Yes, I'll send a rename patch for master. 56157 6 elena.reshetova 2015-11-03 18:36:09 +0000 Thank you very much!