Re: CVE-check failing on world with meta-openembedded: diff.gz file

[Khem Raj <raj.khem@gmail.com>]

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?
> 
> 
> Khem,
> Any feedback about this? From the history it looks like it was you who 
> changed the recipe to use the .diff.gz file.
> 
> Thanks in advance,
> Marta