From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 41560C433FE for ; Wed, 27 Apr 2022 07:15:15 +0000 (UTC) Received: from mail-io1-f51.google.com (mail-io1-f51.google.com [209.85.166.51]) by mx.groups.io with SMTP id smtpd.web11.5322.1651043711377281169 for ; Wed, 27 Apr 2022 00:15:11 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20210112 header.b=mMCgt+tR; spf=pass (domain: gmail.com, ip: 209.85.166.51, mailfrom: rybczynska@gmail.com) Received: by mail-io1-f51.google.com with SMTP id e194so1782556iof.11; Wed, 27 Apr 2022 00:15:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o+Av3UmYe+uepSNCZCopxeVFfOAhHDiwCLMMN3+R17A=; b=mMCgt+tRaOKUsq7cXFm2zPo0uuLF/1crJmUPzu/qTBhYMSjnWO8EMYgqe8q7NzyHg/ VLiYSnmSK92QSx7ruYh+I3JRlCQQy4j6UHF87Q7JieQr50nmYZ50teOuJq4rNkjav6OP 4q4tq6kYeM/anuRKn4Mg7i8lOto5wqGNt4V0Y9PmkJR2qx6IpsLETwrK/6TAS/lJdzNN ldpgnRZY7jaUYGRwX1PtkZjOk2FOmT1bwqlT7nydImEj9DPhPDyyA1kZ0lLmJcVGpjPF f4dzedKqapbDJGjRl89V9x6cZu+Bw0VplXk8lT6BHK4T6sadVb6et6n8d2044EpzYp7M 4c0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=o+Av3UmYe+uepSNCZCopxeVFfOAhHDiwCLMMN3+R17A=; b=OzZMoickSApmgO3XXhBrI9y9rDcKEGLi8SXF3GOedVO4vJ+1wOPSvYYiB+vEEna6cN 1l/6CP3VXKJkQFMfTjvVndSbJ2AmZO1yosmdlm1+YC02E00XHDKPp/PHhkD70ncbHB2+ AhDAli6cBcQaMXJF2Q4tc8uaQKAK1hCh1Dziiw2gzbVLe4kPmK2G4Bdyk9+uFxeBDiTc Ojll7REzL9PwTb+fMpFh+QHzQbmqoxQ05QVCEX25o5RW8xWh9q594D5+MHlehuhevMg+ 7U3gJx6gYCBimb72S7rOu2US12s7hpPoDhOyMcUzThRO0YfZVeLYZiQCxYoY/I9fU2rD tJWg== X-Gm-Message-State: AOAM533QJqk8cXBXjROjgCS1J5xmFNBZnUI/79vNwlhGjASR6ObejOA0 WdRtPy3+U7qOI8eXD0l5rwzfKe+lHM2T2Xo2d7c= X-Google-Smtp-Source: ABdhPJxMk0WZLGvB6lkpI5BJZrFK1qkvklHAgjc8l/gR7LIOu1HkWSOzUHjNaCwls+krAdJvAV76rm++7qOWBH03shQ= X-Received: by 2002:a02:cb03:0:b0:328:8369:9023 with SMTP id j3-20020a02cb03000000b0032883699023mr11949699jap.247.1651043710705; Wed, 27 Apr 2022 00:15:10 -0700 (PDT) MIME-Version: 1.0 References: <5e82785b-14bc-5a4d-a807-fdaa58afee5d@gmail.com> In-Reply-To: <5e82785b-14bc-5a4d-a807-fdaa58afee5d@gmail.com> From: Marta Rybczynska Date: Wed, 27 Apr 2022 09:14:59 +0200 Message-ID: Subject: Re: CVE-check failing on world with meta-openembedded: diff.gz file To: Khem Raj , Ross Burton , Richard Purdie , Steve Sakoman Cc: OE-core , OpenEmbedded Devel List Content-Type: multipart/alternative; boundary="000000000000e2a33505dd9d917b" List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Wed, 27 Apr 2022 07:15:15 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/164890 --000000000000e2a33505dd9d917b Content-Type: text/plain; charset="UTF-8" On Tue, Apr 26, 2022 at 6:09 PM Khem Raj wrote: > Hi Marta > > On 4/26/22 5:20 AM, Marta Rybczynska wrote: > > > > > > On Fri, Apr 22, 2022 at 11:07 AM Marta 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_check > > ERROR: lockdev-1_1.0.3-r0 do_cve_check: File Not found: > > 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: > > /lockdev/1_1.0.3-r0/temp/log.do_cve_check.8709 > > ERROR: Task > > > (/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 --000000000000e2a33505dd9d917b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Apr 26, 2022 at 6:09 PM Khem = Raj <raj.khem@gmail.com> wr= ote:
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:r= ybczynska@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Dear all,
>=C2=A0 =C2=A0 =C2=A0We're running cve-check on a world build contai= ning oe-core, meta-oe
>=C2=A0 =C2=A0 =C2=A0and more. We have an issue with the lockdev recipe<= br> >=C2=A0 =C2=A0 =C2=A0(meta-openembedded/meta-oe/recipes-support/lockdev/= lo= ckdev_1.0.3.bb
>=C2=A0 =C2=A0 =C2=A0<http://lockdev_1.0.3.bb>), which causes a = fail like below:
>
>=C2=A0 =C2=A0 =C2=A0$ bitbake world --runonly=3Ddo_cve_check
>=C2=A0 =C2=A0 =C2=A0ERROR: lockdev-1_1.0.3-r0 do_cve_check: File Not fo= und:
>=C2=A0 =C2=A0 =C2=A0<path>lockdev/1_1.0.3-r0/lockdev_1.0.3-1.6.di= ff
>=C2=A0 =C2=A0 =C2=A0ERROR: lockdev-1_1.0.3-r0 do_cve_check: Failure in = searching patches
>=C2=A0 =C2=A0 =C2=A0ERROR: Logfile of failure stored in:
>=C2=A0 =C2=A0 =C2=A0<path>/lockdev/1_1.0.3-r0/temp/log.do_cve_che= ck.8709
>=C2=A0 =C2=A0 =C2=A0ERROR: Task
>=C2=A0 =C2=A0 =C2=A0(<path>/meta-openembedded/meta-oe/recipes-sup= port/lockdev/lockdev_1.0.3.bb:do_cve_check)
>=C2=A0 =C2=A0 =C2=A0failed with exit code '1'
>
>=C2=A0 =C2=A0 =C2=A0The issue is caused by the fact that lockdev_1.0.3-= 1.6.diff is
>=C2=A0 =C2=A0 =C2=A0missing. When we look into the recipe, it is downlo= ading
>=C2=A0 =C2=A0 =C2=A0lockdev_1.0.3-1.6.diff.gz file Please note the addi= tional extension.
>
>=C2=A0 =C2=A0 =C2=A0Stripping the extension comes from oe-core/meta/oe/= patch.py, from
>=C2=A0 =C2=A0 =C2=A0the patch_path function, which is figuring out if a= file is a patch,
>=C2=A0 =C2=A0 =C2=A0and returning the local path if it is so. However, = at the moment
>=C2=A0 =C2=A0 =C2=A0when we do_cve_check, the .gz file is not uncompres= sed.
>
>=C2=A0 =C2=A0 =C2=A0I'm wondering how to solve it.
>=C2=A0 =C2=A0 =C2=A01. Add a dependency to make sure eventual patch fil= es are
>=C2=A0 =C2=A0 =C2=A0decompressed 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.

>=C2=A0 =C2=A0 =C2=A02. Do not consider this as a patch file in the scop= e of cve-check ?
>=C2=A0 =C2=A0 =C2=A0(this is more a part of the source then an actual p= atch that might
>=C2=A0 =C2=A0 =C2=A0be fixing a CVE)
>
>=C2=A0 =C2=A0 =C2=A0This is the only case like that we have in the buil= d. Please note
>=C2=A0 =C2=A0 =C2=A0that removing ".diff" from the extension = list in patch_path() is
>=C2=A0 =C2=A0 =C2=A0solving the issue.
>
>=C2=A0 =C2=A0 =C2=A0Any comments or suggestions?
>
>
Adding Ross, Richard and= Steve.

I'm wondering if it makes sense to consider .diff.gz (or .patch.gz) f= iles as patches for
cve-check. They basical= ly come directly from 3rd parties and it is quite unlikely to expect
<= div class=3D"gmail_quote">them to keep the CVE: tag. A= ll the pieces of documentation I can find mention also only
.patch files for CVEs, and not .patch.gz.

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

Also, since the co= mmit f5f97d33a1703d75b9fd9760f2c7767081538e00, cve-check
depends only on do_fetch.
Any further opinions?

Regards,
Marta
--000000000000e2a33505dd9d917b--