Hi, On Tue, May 09, 2023 at 09:02:59AM +0000, Ross Burton wrote: > On 8 May 2023, at 09:57, Adrian Freihofer via lists.openembedded.org > <adrian.freihofer=gmail....@lists.openembedded.org> wrote: > > The patch from Andrej tries to solves a real issue: The CVE checker > > distinguishes between two types of patches. Ignored (= not applicable) > > and patched. Patching is only supported by adding a real patch file to > > the SRC_URI. However, there are other ways a patch can be implemented. > > For example, a recipe that uses the git fetcher would update the git > > hash to a commit that contains a fix instead of applying a patch file > > to the recipe. > > > > But I fully agree that the comment (originally suggested by me when > > Andrej and I were discussing the solution) is bad. Maybe it should read > > as follows: > > > > Normally, a CVE is treated as patched when a patch with the name of the > > CVE is applied. CVE_CHECK_PATCHED allows to extend the list of patched > > CVEs without adding a patch file to SRC_URI. > > > > Regarding the SBOM: It is important for customers that the CVEs of a > > product with SBOM can be correctly identified as repaired or as > > ignored. However, I'm not sure if the SBOM part is properly addressed > > by the patch. The create-spdx.bbclass uses the function > > oe.cve_check.get_patched_cves(d) which should probably handle the new > > variable as well. We will check that and come up with a V2. > > So I’d suggest we deprecate CVE_CHECK_IGNORE and add a new, more flexible, > variable instead.
Flexible but usefull and with clear definitions and checks which make sure that only those definitions are used. > How about a CVE_STATUS, which doesn’t have a direct value but has flags for > each CVE: > > # We moved to a git SHA that incorporates the fix > CVE_STATUS[CVE-1234–0001] = “Patched” > > # We disabled frobnicate > CVE_STATUS[CVE-1234-0002] = “Patched” > > # This is Windows-specific > CVE_STATUS[CVE-1234-0003” = “Not Applicable” > > I’m not sure of the exact list of values the flags should accept beyond > “patched” and “not applicable”. There probably does need to be a “reviewed > and don’t consider this a problem” which feels like ‘ignored’ but I’m not a > fan of that precise word. Sounds ok as long as the output reports as easy to read as now. > Is there any defined language that we can simply adopt? Since a lot of people talk about SPDX solving these issues would be nice to know how that is going to work. I can't parse https://spdx.github.io/spdx-spec/v2.3/how-to-use/#k17-linking-to-a-code-fix-for-a-security-issue and figure out how to mark a CVE issue which has been ignored after analysis. Debian has a bit more complex state for each CVE (and also non-CVE security issues) which relates to package and distro versions. I did not find clear definition of the states but at least https://security-tracker.debian.org/tracker/data/json has the raw data available. Ubuntu seems to follow Debian a bit but then also adds more complex states in the (at least) public database at https://ubuntu.com/security/cves?q=CVE-2023-26117&package=&priority=&version=&status= I think the data coming from CVE checker needs to serve the needs of the distro maintainers so that their life is easier. SPDX and SBOM are supposed to help but I'm afraid that they don't unless they actually help with the maintenance and start to solve the problems there. I'm used to the CVE checker ignore list (previously whitelist) and know how to use it. Wether the data comes per CVE or as lists for each of the state as variables is a small detail, as long as the generated report is readable. Cheers, -Mikko
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#181038): https://lists.openembedded.org/g/openembedded-core/message/181038 Mute This Topic: https://lists.openembedded.org/mt/98703185/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
