On Thu, Mar 18, 2021 at 8:31 AM Jamaluddin, Khairul Rohaizzat
<khairul.rohaizzat.jamalud...@intel.com> wrote:
>
> Hi,
>
> Please do correct me if I'm wrong, is the final verdict for glibc on dunfell 
> is to whitelist all the CVEs that were applied before the commit used in 
> SRCREV?
> I'm not really sure what needs to be done here..

My guess is:

1. Bump SRCREV to current head of the 2.31.1 branch
2. Remove patches from the recipe that are already included in the new head
3. See what breaks and fix it ;-)
4. Identify any new CVE's that are fixed as a result of moving to the
new head and add them to the whitelist.

It's unfortunate that we need to deal with keeping the whitelist
accurate, but since upstream doesn't do version bumps there is no way
for the cve checker to know that these fixes are included.

Steve

>
>
> Thank you & Kind regards,
> Khairul
>
> -----Original Message-----
> From: Anatol Belski <anbel...@linux.microsoft.com>
> Sent: Wednesday, March 17, 2021 4:24 AM
> To: Steve Sakoman <st...@sakoman.com>
> Cc: Denys Dmytriyenko <de...@denix.org>; Jamaluddin, Khairul Rohaizzat 
> <khairul.rohaizzat.jamalud...@intel.com>; Khem Raj <raj.k...@gmail.com>; 
> Patches and discussions about the oe-core layer 
> <openembedded-core@lists.openembedded.org>
> Subject: Re: [OE-core] [PATCH] glibc: Fix CVE-2021-27645
>
> Hi,
>
> On 3/16/2021 4:45 PM, Steve Sakoman wrote:
> > On Tue, Mar 16, 2021 at 2:56 AM Anatol Belski
> > <anbel...@linux.microsoft.com> wrote:
> >> Hi,
> >>
> >> On 3/15/2021 10:36 PM, Denys Dmytriyenko wrote:
> >>> https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS#Stable.2FL
> >>> TS_Patch_Acceptance_Policies
> >>>
> >>> Stable/LTS Patch Acceptance Policies
> >>>
> >>> Potentially Acceptable:
> >>> * Bug fix only version upgrades for upstreams with a good stable
> >>> process
> >>>
> >>> Unacceptable:
> >>> * General version upgrades
> >>>
> >>>
> >>> So, unless there's a bugfix-only minor release of glibc, e.g.
> >>> 2.31.1, upgrading to 2.32 or 2.33 in stable branches is highly
> >>> unlikely, as both
> >>> 2.32 and 2.33 have long lists of major changes:
> >>>
> >>> https://sourceware.org/pipermail/libc-announce/2020/000029.html
> >>> https://sourceware.org/pipermail/libc-announce/2021/000030.html
> >> thanks for linking the LTS doc.
> >>
> >> My suggestion was to pull the latest upstream from 2.31 actually, not
> >> upgrading the glibc version. As per
> >>
> >> http://git.yoctoproject.org/clean/cgit.cgi/poky/tree/meta/recipes-cor
> >> e/glibc/glibc-version.inc?h=dunfell
> >>
> >> we consume from the branch release/2.31/master. It already contains
> >> the backported patch fixing this CVE.
> >>
> >> There doesn't seem to be a release process in terms of versions, but
> >> it regularly receives backports. In fact,
> >>
> >> there are already some bug and CVE fixes between the current SRCREV
> >> used and HEAD.
> > I'd be happy to take such a patch for dunfell.
> >
> > I'll add it to my to do list to look into this, but if someone has the
> > time/inclination to tackle this it might get done sooner :-)
> >
> > Since there is no versioning from upstream it will be important in
> > this patch to make sure that we whitelist all of the CVE's that are
> > fixed with the bump in SRCREV.
> >
> I'd be able to do a run on this closer to the end of this week, if no one 
> beats me to it (perhaps Khairul, the initial patch contributor ;)).
>
> Regards
>
> Anatol
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149645): 
https://lists.openembedded.org/g/openembedded-core/message/149645
Mute This Topic: https://lists.openembedded.org/mt/81255047/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to