| Message ID | 20250414141150.994811-1-raphael.melotte@mind.be |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | [1/1] package/apparmor: ignore CVE-2016-1585 | expand |
Hello Raphaël, On Mon, 14 Apr 2025 16:11:48 +0200 Raphaël Mélotte via buildroot <buildroot@buildroot.org> wrote: > CVE-2016-1585 is fixed in the following versions: > apparmor 3.1.6 https://gitlab.com/apparmor/apparmor/-/wikis/Release_Notes_3.1.6 > apparmor 3.0.12 https://gitlab.com/apparmor/apparmor/-/wikis/Release_Notes_3.0.12 > apparmor 2.13.10 https://gitlab.com/apparmor/apparmor/-/wikis/Release_Notes_2.13.10 > > See the bug report at [1] and in particular the comment at [2]. > > The NVD CPE does not contain version numbers, so our CVE checker still > reports it. > The issue was reported to the NVD by email, but in the meantime let's > ignore it to reduce the noise in our CVE checker. Thanks for the patch. However, I'm not sure I'm happy with ignoring entries that are ultimately "bugs" in the NVD database. Have you heard back from upstream NVD about your report? In fact, I'm worried about this APPARMOR_IGNORE_CVES staying forever. Does our pkg-stats script report those stale CVE entries? If it did, then we could consider merging your patch, because we know that once the NVD database gets updated, we'll get a warning/notification from pkg-stats that this APPARMOR_IGNORE_CVES entry should be dropped. Best regards, Thomas
Hi Thomas, On 4/19/25 16:05, Thomas Petazzoni wrote: > [...] > Have you heard back from upstream NVD about your report? No, I haven't. I've made such reports in the past and I get the impression that while they sometimes do get processed, sometimes they don't (or with a long delay?). > In fact, I'm worried about this APPARMOR_IGNORE_CVES staying forever. > Does our pkg-stats script report those stale CVE entries? If it did, > then we could consider merging your patch, because we know that once > the NVD database gets updated, we'll get a warning/notification from > pkg-stats that this APPARMOR_IGNORE_CVES entry should be dropped. That's a good point, I don't think pkg-stats reports such issues with our CVE entries yet so we have no way to find and remove those entries. I gave it a quick try: https://patchwork.ozlabs.org/project/buildroot/patch/20250423152906.1017522-1-raphael.melotte@mind.be/ Kind regards, Raphaël
Hello Raphaël, On Wed, 23 Apr 2025 17:32:48 +0200 Raphaël Mélotte <raphael.melotte@mind.be> wrote: > No, I haven't. > I've made such reports in the past and I get the impression that > while they sometimes do get processed, sometimes they don't (or with > a long delay?). On my side, they always replied, but with a huge delay. That being said, I'm sure you're aware that federal agencies in the US are these days having some sort of troubles in getting their funding, which might explain some of the slowness :-) > That's a good point, I don't think pkg-stats reports such issues with > our CVE entries yet so we have no way to find and remove those > entries. > > I gave it a quick try: > https://patchwork.ozlabs.org/project/buildroot/patch/20250423152906.1017522-1-raphael.melotte@mind.be/ Super nice! Out of curiosity, do we have stale entries as of today? But with that in place, I would definitely be more keen to accept IGNORE_CVES entries for things that ultimately should be fixed in NVD's database. Best regards, Thomas
On 4/23/25 17:37, Thomas Petazzoni wrote: > > On my side, they always replied, but with a huge delay. > > That being said, I'm sure you're aware that federal agencies in the US > are these days having some sort of troubles in getting their funding, > which might explain some of the slowness :-) > Indeed... > > Super nice! Out of curiosity, do we have stale entries as of today? > I'm not entirely sure my changes are working as expected (which is also why I sent them as an RFC), but if I trust them I get: Packages with stale CVE ignores: 10 Total number of stale CVE ignores affecting all packages: 28 CVE-2020-15705 for grub2 (the first one I randomly chose in the list) indeed now has "Up to (including) 2.04" in the NVD (see [1]) so there is at least one reported correctly. Kind regards, Raphaël [1]: https://nvd.nist.gov/vuln/detail/CVE-2020-15705
diff --git a/package/apparmor/apparmor.mk b/package/apparmor/apparmor.mk index 61e62c7515..0fa56a00f0 100644 --- a/package/apparmor/apparmor.mk +++ b/package/apparmor/apparmor.mk @@ -14,6 +14,10 @@ APPARMOR_LICENSE = GPL-2.0 APPARMOR_LICENSE_FILES = LICENSE parser/COPYING.GPL APPARMOR_CPE_ID_VENDOR = canonical +# The following CVE was fixed in 3.1.4 but the NVD CPE does not +# contain version numbers +APPARMOR_IGNORE_CVES += CVE-2016-1585 + APPARMOR_DEPENDENCIES = libapparmor APPARMOR_TOOLS = parser
CVE-2016-1585 is fixed in the following versions: apparmor 3.1.6 https://gitlab.com/apparmor/apparmor/-/wikis/Release_Notes_3.1.6 apparmor 3.0.12 https://gitlab.com/apparmor/apparmor/-/wikis/Release_Notes_3.0.12 apparmor 2.13.10 https://gitlab.com/apparmor/apparmor/-/wikis/Release_Notes_2.13.10 See the bug report at [1] and in particular the comment at [2]. The NVD CPE does not contain version numbers, so our CVE checker still reports it. The issue was reported to the NVD by email, but in the meantime let's ignore it to reduce the noise in our CVE checker. [1]: https://bugs.launchpad.net/apparmor/+bug/1597017 [2]: https://bugs.launchpad.net/apparmor/+bug/1597017/comments/9 Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be> --- package/apparmor/apparmor.mk | 4 ++++ 1 file changed, 4 insertions(+)