On Thu, 2024-08-01 at 15:58 +0200, Marta Rybczynska wrote: > On Thu, Aug 1, 2024 at 3:47 PM Richard Purdie > <[email protected]> wrote: > > On Fri, 2024-07-26 at 14:28 +0200, Marta Rybczynska via > > lists.openembedded.org wrote: > > > On Fri, Jul 26, 2024 at 2:24 PM Ross Burton <[email protected]> > > > wrote: > > > > On 24 Jul 2024, at 16:25, Marta Rybczynska via > > > > lists.openembedded.org > > > > <[email protected]> wrote: > > > > > > > > > > This file contains CVE_STATUS without machine-readable > > > > > information on which > > > > > recipe it applies to. All entries should be verified and, if > > > > > appropriate, > > > > > moved to their corresponding recipes. > > > > > > > > The point of this file was to be an opt-in for more exclusions > > > > where we didn’t feel 100% confident asserting the issues could be > > > > ignored. > > > > > > > > How much of a problem is it if this file contains a a limited > > > > number of CVEs? We can review what is in there and move/remove as > > > > needed to cut it down. > > > > > > With the vex class (and with SPDX too, I think) they end up copied > > > present in every single package of the build. This brings enormous > > > confusion. > > > Impossible to filter them out as there is no information about the > > > affected recipe/package. > > > > Difficult, yes, impossible, no. > > > > Surely we know which recipes a given CVE apply to? > > Without having the CVE data at the same time, no.
I thought we had the CVE data? > Also, a CVE might apply to multiple > recipes at the same time - and this could be dangerous. Imagine a situation > where > the CPE is incorrect and is pointing to the wrong package. It gets added to > .inc. > But then someone in their layer adds the package the CVE really applies to... We can't cover every possible scenario and if the data is wrong, we identify and fix it. > If we keep the .inc file, I think the most correct way would be to add a > field marking > which recipe it should be applied to. > > What do you think? How do we mark up a CVE as applying to gcc-cross-*/gcc-cross-canadian- */gcc-runtime/libgcc and so on? How do we convert "bash" to "nativesdk-bash" and "bash-native"? There are ways we could do such markup but I don't think it is going to work well. I guess the key question is what we're trying to achieve and where we're expecting the data to be processed? Could we write a common exclusion file out once as part of the CVE fetch recipe and avoid putting it into the individual recipe output? Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#202737): https://lists.openembedded.org/g/openembedded-core/message/202737 Mute This Topic: https://lists.openembedded.org/mt/107525297/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
