On Tue, 2023-05-09 at 09:02 +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. > > 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. > > Is there any defined language that we can simply adopt?
The question is probably what actions might someone want to take? We might want to separate out "N/A - configuration disabled" from "N/A - OS mismatch" and "CPE incorrect" for example? The reason being that someone would then know to look at things more closely if they were changing configuration, or building windows binaries? Given we already put fairly robust reasoning in comments already, should we capture that in a variable too? CVS_STATUS_REASONING[[CVE-1234-0003] = "issue only applies on windows" Cheers, Richard (thinking out loud)
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#181037): https://lists.openembedded.org/g/openembedded-core/message/181037 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] -=-=-=-=-=-=-=-=-=-=-=-
