Date
1 - 4 of 4
CVE-check failing on world with meta-openembedded: diff.gz file
Marta Rybczynska
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), 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'
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?
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?
Kind regards,
Marta
Marta Rybczynska
On Fri, Apr 22, 2022 at 11:07 AM Marta Rybczynska <rybczynska@...> 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), which causes a fail like below:$ bitbake world --runonly=do_cve_checkERROR: 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?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
Hi Marta
On 4/26/22 5:20 AM, Marta Rybczynska wrote:
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.
On 4/26/22 5:20 AM, Marta Rybczynska wrote:
On Fri, Apr 22, 2022 at 11:07 AM Marta Rybczynska <rybczynska@... <mailto:rybczynska@...>> 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
Marta Rybczynska
On Tue, Apr 26, 2022 at 6:09 PM Khem Raj <raj.khem@...> 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@...
> <mailto:rybczynska@...>> 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