On Tue, Apr 26, 2022 at 6:09 PM Khem Raj <raj.khem@gmail.com> wrote:

> Hi Marta
>
> On 4/26/22 5:20 AM, Marta Rybczynska wrote:
> >
> >
> > On Fri, Apr 22, 2022 at 11:07 AM Marta Rybczynska <rybczynska@gmail.com
> > <mailto:rybczynska@gmail.com>> wrote:
> >
> >     Dear all,
> >     We're running cve-check on a world build containing oe-core, meta-oe
> >     and more. We have an issue with the lockdev recipe
> >     (meta-openembedded/meta-oe/recipes-support/lockdev/lockdev_1.0.3.bb
> >     <http://lockdev_1.0.3.bb>), which causes a fail like below:
> >
> >     $ bitbake world --runonly=do_cve_check
> >     ERROR: lockdev-1_1.0.3-r0 do_cve_check: File Not found:
> >     <path>lockdev/1_1.0.3-r0/lockdev_1.0.3-1.6.diff
> >     ERROR: lockdev-1_1.0.3-r0 do_cve_check: Failure in searching patches
> >     ERROR: Logfile of failure stored in:
> >     <path>/lockdev/1_1.0.3-r0/temp/log.do_cve_check.8709
> >     ERROR: Task
> >
>  (<path>/meta-openembedded/meta-oe/recipes-support/lockdev/lockdev_1.0.3.bb:
> do_cve_check)
> >     failed with exit code '1'
> >
> >     The issue is caused by the fact that lockdev_1.0.3-1.6.diff is
> >     missing. When we look into the recipe, it is downloading
> >     lockdev_1.0.3-1.6.diff.gz file Please note the additional extension.
> >
> >     Stripping the extension comes from oe-core/meta/oe/patch.py, from
> >     the patch_path function, which is figuring out if a file is a patch,
> >     and returning the local path if it is so. However, at the moment
> >     when we do_cve_check, the .gz file is not uncompressed.
> >
> >     I'm wondering how to solve it.
> >     1. Add a dependency to make sure eventual patch files are
> >     decompressed first?
>
>
> I think this option looks best or perhaps we should drop applying debian
> diff entirely since debian seems to have dropped this package
>
> I think regardless of what we do with this package it seems to be a
> limitation of cve-check process which perhaps should either be fixed or
> documented.
>
> >     2. Do not consider this as a patch file in the scope of cve-check ?
> >     (this is more a part of the source then an actual patch that might
> >     be fixing a CVE)
> >
> >     This is the only case like that we have in the build. Please note
> >     that removing ".diff" from the extension list in patch_path() is
> >     solving the issue.
> >
> >     Any comments or suggestions?
> >
> >

Adding Ross, Richard and Steve.

I'm wondering if it makes sense to consider .diff.gz (or .patch.gz) files
as patches for
cve-check. They basically come directly from 3rd parties and it is quite
unlikely to expect
them to keep the CVE: tag. All the pieces of documentation I can find
mention also only
.patch files for CVEs, and not .patch.gz.

This is tempting to remove the .gz handling here (for the cve-check) in my
opinion.

Also, since the commit f5f97d33a1703d75b9fd9760f2c7767081538e00, cve-check
depends only on do_fetch.

Any further opinions?

Regards,
Marta