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

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

[Anatol Belski]

The naming convention needs to be help so the CVE is recognized as
fixed by the tooling.

Signed-off-by: Anatol Belski <anbelski@linux.microsoft.com>
---
 ...ion-to-avoid-GOptionEntry-lis.patch => CVE-2020-35457.patch} | 0
 meta/recipes-core/glib-2.0/glib-2.0_2.62.6.bb                   | 2 +-
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-core/glib-2.0/glib-2.0/{0001-goption-Add-a-precondition-to-avoid-GOptionEntry-lis.patch => CVE-2020-35457.patch} (100%)

diff --git a/meta/recipes-core/glib-2.0/glib-2.0/0001-goption-Add-a-precondition-to-avoid-GOptionEntry-lis.patch b/meta/recipes-core/glib-2.0/glib-2.0/CVE-2020-35457.patch
similarity index 100%
rename from meta/recipes-core/glib-2.0/glib-2.0/0001-goption-Add-a-precondition-to-avoid-GOptionEntry-lis.patch
rename to meta/recipes-core/glib-2.0/glib-2.0/CVE-2020-35457.patch
diff --git a/meta/recipes-core/glib-2.0/glib-2.0_2.62.6.bb b/meta/recipes-core/glib-2.0/glib-2.0_2.62.6.bb
index 0ad14a0878..1a006b9f38 100644
--- a/meta/recipes-core/glib-2.0/glib-2.0_2.62.6.bb
+++ b/meta/recipes-core/glib-2.0/glib-2.0_2.62.6.bb
@@ -17,7 +17,7 @@ SRC_URI = "${GNOME_MIRROR}/glib/${SHRT_VER}/glib-${PV}.tar.xz \
            file://0001-meson-Run-atomics-test-on-clang-as-well.patch \
            file://0001-gio-tests-resources.c-comment-out-a-build-host-only-.patch \
            file://tzdata-update.patch \
-           file://0001-goption-Add-a-precondition-to-avoid-GOptionEntry-lis.patch \
+           file://CVE-2020-35457.patch \
            "
 
 SRC_URI_append_class-native = " file://relocate-modules.patch"
-- 
2.17.1

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

[Mikko Rapeli]

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

Is there some other tooling that you are referring to?

Cheers,

-Mikko

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

[Steve Sakoman]

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.

Steve

> Is there some other tooling that you are referring to?
>
> Cheers,
>
> -Mikko
> 
>

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

[Anatol Belski]

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

Hi,

On 2/3/2021 11:02 AM, Mikko Rapeli 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
>
> Is there some other tooling that you are referring to?

I should have read meta/classes/cve-check.bbclass before :) Looks like 
it was a wrong impression on my side, that the filename needs to match 
there, also when working with older versions. Thanks for the 
explanation, indeed there's no action required on this, I didn't refer 
to any other tools.

Regards

Anatol

> Cheers,
>
> -Mikko
>
> 
>

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

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

[Anatol Belski]

Hi,

On 2/3/2021 3:38 PM, 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.

Thanks for pointing this out. On my side, I also always check this one

https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines

There's no explicit mention on the filename, but I guess i sure read the 
other page, too. Perhaps the effort would be better put adding a word on 
the wiki, that the filename is not really relevant. And otherwise, seems 
there's nothing to fix other than my habit on seeing the filename to be 
same as CVE :)

Thanks!

Anatol

> Steve
>
>> Is there some other tooling that you are referring to?
>>
>> Cheers,
>>
>> -Mikko
>> 
>>

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

[Mikko Rapeli]

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

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

[Steve Sakoman]

On Wed, Feb 3, 2021 at 5:53 AM Mikko Rapeli <mikko.rapeli@bmw.de> wrote:
>
> 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?

I wasn't involved in defining the requirements, but I suspect that it
is to make it easy to
see with a glance of the recipe which patches are CVE fixes.

I like it for this reason, but as you say it doesn't affect the cve
checker script.

Steve

> 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
> 
>