On Sun, May 9, 2021 at 8:17 AM akuster808 <akuster...@gmail.com> wrote: > On 5/6/21 10:12 AM, Steve Sakoman wrote: > > The preferred methods for CVE resolution are: > > > > 1. Version upgrades where possible > > 2. Patches where not possible > > 3. Database updates where version info is incorrect > > 4. Exclusion from checking where it is determined that the CVE > > does not apply to our environment
> I do see the desire of doing this as it is one file to maintain if there > are multiple packages being updated at once. No, that isn't the intent of this at all! The above four methods are still the desired method to deal with CVE's on a per recipe basis, even if a CVE applies to multiple packages (quite rare). > This does highlight a few > things to me: > > 1) We have been dealing with this on a per-recipe basis. This is a shift > from that. ( Does this need to be documented) As I stated above, this is not the intent. > 2) Recipe Maintainers aren't engage in this area of activity as we had > original hoped. So we are working around that. True, they haven't. But, no, working around lack of engagement is not the intent! See my last two paragraphs in the original patch for my intent. > Reporting a false positive is better than masking an actual issue IMHO. I agree completely, and this is why this mechanism is optional. > So what was the Policy used to decide on what can be put into this file? > Did I miss that conversion ? Is it documented anywhere? See the next two paragraphs from the original patch. If you have some suggestions on how to better explain that this file is for ancient/intractable CVE's I would be happy to update the wording so there is no confusion! Same goes for the leading comment in the include file. Suggestions for revisions to the wording are welcome! > > In some cases none of these methods are possible. For example the > > CVE may be decades old with no apparent resolution, and with broken > > links that make further research impractical. > > > > This patch creates a mechanism for users to remove this type of > > CVE from the cve-check results via an optional include file. > > > > Signed-off-by: Steve Sakoman <st...@sakoman.com> > > --- > > .../distro/include/cve-extra-exclusions.inc | 18 ++++++++++++++++++ > > 1 file changed, 18 insertions(+) > > create mode 100644 meta/conf/distro/include/cve-extra-exclusions.inc > > > > diff --git a/meta/conf/distro/include/cve-extra-exclusions.inc > > b/meta/conf/distro/include/cve-extra-exclusions.inc > > new file mode 100644 > > index 0000000000..956b3a9a3c > > --- /dev/null > > +++ b/meta/conf/distro/include/cve-extra-exclusions.inc > > @@ -0,0 +1,18 @@ > > +# This file contains a list of CVE's where resolution has proven to be > > impractical. > > +# It contains all the information we are aware of about an issue and > > analysis about > > +# why we believe it can't be fixed/handled. Additional information is > > welcome through > > +# patches to the file. > > +# > > +# Include this file in your local.conf or distro.conf to exclude these > > CVE's > > +# from the cve-check results > > + > > +# strace https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2000-0006 > > +# CVE is more than 20 years old with no resolution evident > > +# broken links in CVE database references make resolution impractical > > +CVE_CHECK_WHITELIST += "CVE-2000-0006" > > + > > +# groff:groff-native > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2000-0803 > > +# CVE is more than 20 years old with no resolution evident > > +# broken links in CVE database references make resolution impractical > > +CVE_CHECK_WHITELIST += "CVE-2000-0803" > > + > > > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#151493): https://lists.openembedded.org/g/openembedded-core/message/151493 Mute This Topic: https://lists.openembedded.org/mt/82635461/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
