Re: [Buildroot] [RFC PATCH 08/14] package/python-pip: add detail to vulnerability

[Thomas Perale via buildroot <buildroot@buildroot.org>]

Hi Fiona,

Thanks for already taking the time to look at this series.

In reply of:
> Hi Thomas!
> 
> Am 24.06.26 um 16:06 schrieb Thomas Perale via buildroot:
> > The vulnerability is marked as fixed as it work as expected according to
> > the upstream project.
> > > Signed-off-by: Thomas Perale <thomas.perale@mind.be>
> > ---
> >   package/python-pip/python-pip.mk | 5 +++--
> >   1 file changed, 3 insertions(+), 2 deletions(-)
> > > diff --git a/package/python-pip/python-pip.mk b/package/python-pip/python-pip.mk
> > index d12bea3225..ae9a4225eb 100644
> > --- a/package/python-pip/python-pip.mk
> > +++ b/package/python-pip/python-pip.mk
> > @@ -12,9 +12,10 @@ PYTHON_PIP_LICENSE = MIT
> >   PYTHON_PIP_LICENSE_FILES = LICENSE.txt
> >   PYTHON_PIP_CPE_ID_VENDOR = pypa
> >   PYTHON_PIP_CPE_ID_PRODUCT = pip
> > -# Disputed CVE: things work as designed, and only affects the
> > -# --extra-index-url option. This CVE will never be fixed.
> > +
> >   PYTHON_PIP_IGNORE_CVES += CVE-2018-20225
> > +PYTHON_PIP_CVE-2018-20225_STATUS = fixed
> > +PYTHON_PIP_CVE-2018-20225_DETAIL = Disputed CVE: things work as designed, and only affects the --extra-index-url option. This CVE will never be fixed.
> 
> I don't like using "fixed" for "upstream maintainers don't see this as a problem". Nothing was fixed, the dispute is whether anything needs fixing.
> 

I definitely agree and I don't like it either but I feel that the options
OpenVex and CycloneDX provides are limited for that specific case.

If I understand correctly it's because you need to actually put the upstream
project justification in a category.

For example for the flex example the project disputed the vulnerability by
claiming it doesn't produce a vulnerable code so I used the
"not-affected-vulnerable-code-not-present" category.

Here my logic was that since it's the expected behavior it's not a
vulnerability at all and then could mark it as fixed. But indeed I
over-interpret the "fixed" category.

> Looking at the OpenVEX status labels "not_affected" or "under_investigation" seem to fit better (depending on whether we agree with upstream or not, I guess if we don't adding to IGNORE_CVES would be questionable), but I don't see any way to clearly express "disputed" among those options.

For the "under_investigation", it means this would map to "in_triage" for
CycloneDX and that's what I'm trying to remove with this series to be able to
filter any vulnerabilities that don't provide a "status".

For "not_affected" the spec specify that we need to provide a justification
with it [1]. But I don't see a justification that really suits this specific
case.

To be honest, the more I look at the categories and the one I already assigned
to the packages the more I think other categories could be used as a
justification. It's really confusing.

Best regards,
PERALE Thomas

[1] https://cyclonedx.org/docs/1.7/json/#vulnerabilities_items_analysis_justification
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot