On Thu, Aug 1, 2024 at 4:08 PM Richard Purdie < [email protected]> wrote:
> 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? > When we do vex only, we have the CVE data only in the external tool. The file that comes out from the build contains additional entries. We can filter them out, but only in the tool. However, if we filter out in the tool (with a rule like: if this CVE does not apply to the package, remove it), we remove the feature of the VEX of being able to specify that your package is not affected by a widely known vulnerability. For example, you can say "I'm not affected by log4shell because I do not include log4j". This is a feature that has its use, it avoids responding to multiple procurement questions, where they all want the same information. You just say it once, in the VEX. > > > 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. > I think we need to distinguish between two cases: - the data is wrong and we fix it (and we're sure of the fix) - typically a CPE fix - the resolution depends on a configuration, typically "not-applicable-config" - if someone adds a bbappend to the recipe, they MUST review impact on all related vulnerabilities - we make an assumption. All of "upstream-wontfix" are of this category. The YP user MUST make their own assessment here. > > > 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? > We do not have any gcc entries in cve-extra-exclusions. > > How do we convert "bash" to "nativesdk-bash" and "bash-native"? > We do not have anything related to bash either. What is in there in cve-extra-exclusions are mostly very old CVEs, the biggest part belonging to bdb. Kernel ones can go to kernel includes etc. With the directions the CVE programme is going, I do not *expect* a need for new entries. > > 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? > Yes, we can do that and additionally allow each vendor to have their own file, with their own assessment. "upstream-wontfix" can be mapped to "code-not-reached" or similar, when confirmed this is not explotable. Autobuilder can have its own removing entries we don't want to see on CVE list (if we really think it is a good idea). Regards, Marta > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#203023): https://lists.openembedded.org/g/openembedded-core/message/203023 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]] -=-=-=-=-=-=-=-=-=-=-=-
