On Tue, 2024-08-06 at 15:16 +0200, Marta Rybczynska wrote: > 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: > > > > 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.
Since we're using CVE entries with CVE numbering, I think it is ok if even in the vex path, we perform some evaluation to see if a given CVE_STATUS applies to a given recipe, particularly if we're exporting data specific to that recipe. The code change in question doesn't just change VEX but the general CVE output too. > 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. By that argument, you could export every CVE possible against every recipe :/. > > 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. The user needs to make an assessment, sure, but are we then going to force the user to bbappend every recipe with their assessment? > > > 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. No, but we, or a downstream user might need to do this. > > How do we convert "bash" to "nativesdk-bash" and "bash-native"? > > We do not have anything related to bash either. Today, no. Tomorrow, or in some other product with a different configuration. > 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. However, this mechanism is also the mechanism someone building a product and performing their own assessments may want to use. What your patches do is force all of that into the end tooling and out of the metadata and make the metadata completely impractical to do it with. That simply isn't acceptable. > > 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. You mean like an .inc file? > 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). This is exactly what the file you want to deprecate does. I agreed to put it in the public metadata where people could see what we were doing and why, so they could them make their own assessment of what we've done. I'm afraid I am adamant we cannot drop support for this. (I am also find with reducing the entries in that file, I just think we can't entirely remove support for the capability) Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#203025): https://lists.openembedded.org/g/openembedded-core/message/203025 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]] -=-=-=-=-=-=-=-=-=-=-=-
