Re: [OE-core] [dunfell][PATCH] glib-2.0: Rename patch file for CVE-2020-35457

["Mikko Rapeli" <mikko.rapeli@bmw.de>]

On Wed, Feb 03, 2021 at 04:38:58AM -1000, Steve Sakoman wrote:
> On Wed, Feb 3, 2021 at 12:02 AM Mikko Rapeli <mikko.rapeli@bmw.de> wrote:
> >
> > Hi,
> >
> > On Wed, Feb 03, 2021 at 08:42:57AM +0000, Anatol Belski wrote:
> > > The naming convention needs to be help so the CVE is recognized as
> > > fixed by the tooling.
> >
> > Yocto CVE checker does detect CVE patches also from patch comments so
> > this change is not needed for that. This is sufficient:
> >
> > poky$ git grep CVE-2020-35457
> > meta/recipes-core/glib-2.0/glib-2.0/0001-goption-Add-a-precondition-to-avoid-GOptionEntry-lis.patch:CVE: CVE-2020-35457
> 
> Yes, we are detecting the CVE patch from the patch comment.
> 
> However our CVE patch guidelines do request that the patch be named
> with the CVE as the name:
> 
> https://wiki.yoctoproject.org/wiki/Security
> 
> (in the "Patch name convention and commit message" section)
> 
> I'm sorry I didn't catch this when I merged this earlier.  I always
> check the patch itself for the CVE tag, but I missed the name.  So I'm
> happy to take this patch just to clean up the metadata and make it
> easy to see that this is a CVE patch.

Does anyone know why CVE ID in both name of the patch and in the CVE: tag are required?

Sometimes when copying patches over from upstream or other distros, I prefer to do as
little changes to them as possible. Adding CVE: tag and Upstream-Status are ok, but
for example renaming all patches files copied from a Debian/Ubuntu patch set is
a bit too much.

Cheers,

-Mikko