On Fri, 2021-05-07 at 06:02 +0000, Mikko Rapeli wrote: > Hi, > > On Thu, May 06, 2021 at 07:12:32AM -1000, Steve Sakoman wrote: > > The preferred methods for CVE resolution are: > > > > 1. Version upgrades where possible > > 2. Patches where not possible > > 3. Database updates where version info is incorrect > > 4. Exclusion from checking where it is determined that the CVE > > does not apply to our environment > > > > In some cases none of these methods are possible. For example the > > CVE may be decades old with no apparent resolution, and with broken > > links that make further research impractical. > > > > This patch creates a mechanism for users to remove this type of > > CVE from the cve-check results via an optional include file. > > > > Signed-off-by: Steve Sakoman <st...@sakoman.com> > > --- > > .../distro/include/cve-extra-exclusions.inc | 18 ++++++++++++++++++ > > 1 file changed, 18 insertions(+) > > create mode 100644 meta/conf/distro/include/cve-extra-exclusions.inc > > > > diff --git a/meta/conf/distro/include/cve-extra-exclusions.inc > > b/meta/conf/distro/include/cve-extra-exclusions.inc > > new file mode 100644 > > index 0000000000..956b3a9a3c > > --- /dev/null > > +++ b/meta/conf/distro/include/cve-extra-exclusions.inc > > @@ -0,0 +1,18 @@ > > +# This file contains a list of CVE's where resolution has proven to be > > impractical. > > +# It contains all the information we are aware of about an issue and > > analysis about > > +# why we believe it can't be fixed/handled. Additional information is > > welcome through > > +# patches to the file. > > +# > > +# Include this file in your local.conf or distro.conf to exclude these > > CVE's > > +# from the cve-check results > > + > > +# strace https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2000-0006 > > +# CVE is more than 20 years old with no resolution evident > > +# broken links in CVE database references make resolution impractical > > +CVE_CHECK_WHITELIST += "CVE-2000-0006" > > Could this be specific to a recipe? > > It may be that CVE data changes and adds new CPEs and the same CVE could still > be valid for another recipe. I think the analysis also applies to a single > recipe.
I've been discussing this with Steve a bit. My concern and motivation for this is that we have a set of CVEs which are proving hard to find any useful data about and that we can do little to address, particularly the ones 10-20 years old. Having those showing up on weekly reports when we can do little about them is painting the situation a little unfairly. Whitelisting them in the recipes is also not entirely appropriate though. This file is primarily intended to collect up a list of those along with what information we do know. For more recent entries with better data, I'd expect we either fix them or we can handle on a per recipe basis. The entries in this file are likely to be the really old ones which are very unlikely to change. We've left the file as opt-in so users have to choose whether they want this data but it gives us a way to document any investigation done and what the status is. In answer to the specific question, we could likely use pn- overrides here I guess but for the kinds of CVEs likely to be listed, I'm not sure it gains us much? Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#151411): https://lists.openembedded.org/g/openembedded-core/message/151411 Mute This Topic: https://lists.openembedded.org/mt/82635461/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
