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

From: Khem Raj <raj.khem@gmail.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: OE-core <openembedded-core@lists.openembedded.org>,
	Ross Burton <Ross.Burton@arm.com>,
	Steve Sakoman <steve@sakoman.com>,
	"rybczynska@gmail.com" <rybczynska@gmail.com>
Subject: Re: [oe] CVE-check failing on world with meta-openembedded: diff.gz file
Date: Wed, 27 Apr 2022 07:55:32 -0700	[thread overview]
Message-ID: <CAMKF1sqdtij84OPpw+p8B-OoNUU-=cUo6AmG5ousZp0xO5aY3w@mail.gmail.com> (raw)
In-Reply-To: <6dff4bbd3390a8e6f7103210eb8e8d74d9cb239c.camel@linuxfoundation.org>

[-- Attachment #1: Type: text/plain, Size: 2362 bytes --]

On Wed, Apr 27, 2022 at 3:33 AM Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> On Wed, 2022-04-27 at 10:32 +0000, Ross Burton wrote:
> > On 27 Apr 2022, at 08:14, Marta Rybczynska via lists.openembedded.org
> > <rybczynska=gmail.com@lists.openembedded.org> wrote:
> > > 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.
> >
> > The patch being a .patch.gz isn’t entirely relevant, it’s the fact that
> it’s a
> > remote http: patch not a local file: patch which is causing the problem.
> The
> > code uses the localpath, which only exists for remote URL after
> do_unpack.
> >
> > There are three alternatives here:
> > 1) Only consider local patches.  Any remote patches won’t be scanned,
> but they
> > don’t work anyway right now. This might mean the dependency on do_fetch
> can be
> > dropped to speed up checking even further.
> > 2) Change the task dependency to be on do_unpack instead of do_fetch.
> This
> > will slow down processing if a build hasn’t already happened as tarballs
> will
> > be unpacked, but remote files will be present for scanning then.
> > 3) Try to be clever and manually call unpack on remote files.  More
> > complicated but preserves the speed.
> >
> > I’m actually undecided over what the best solution is. Clearly we need
> some
> > test cases for this code too.
>
> I think the deciding factor may be that most remote patches probably don't
> have
> the information we're looking for in them anyway?


I think covering more cases has value if it can be done in a reasonable
manner without punishing the system too much otherwise a diagnostic message
should definitely be an improvement which will nudge the user to perhaps
change the patch mechanism like we did for lockdev

>
> Cheers,
>
> Richard
>
>

[-- Attachment #2: Type: text/html, Size: 3265 bytes --]