[kirkstone] Google go CVEs

[kirkstone] Google go CVEs

[Valek, Andrej]

Hello everyone,

I would like to ask you how to proceed with multiple CVEs for Google Go
component in kirkstone branch.

CVEs in current version 1.17.13:
- CVE-2022-41722
- CVE-2022-41725
- CVE-2022-41724
- CVE-2022-41723

They are fixed in 1.19.6/1.20.1 branches, but a fixing patches are
available for all of them too. Unfortunately there is more then ~1000
changed LOC. So not sure if this is the right approach to apply them.
Not sure if the upgrade is acceptable.

So how to proceed with this?

I know, that they aren't a critical one, but would be nice to have them
fixed.

Regards,
Andrej

Re: [OE-core] [kirkstone] Google go CVEs

[Alexander Kanavin]

You probably should make a kirkstone mixin layer like we did for dunfell.
https://git.yoctoproject.org/meta-lts-mixins/

Alex

On Tue, 7 Mar 2023 at 07:32, Andrej Valek <andrej.valek@siemens.com> wrote:
>
> Hello everyone,
>
> I would like to ask you how to proceed with multiple CVEs for Google Go
> component in kirkstone branch.
>
> CVEs in current version 1.17.13:
> - CVE-2022-41722
> - CVE-2022-41725
> - CVE-2022-41724
> - CVE-2022-41723
>
> They are fixed in 1.19.6/1.20.1 branches, but a fixing patches are
> available for all of them too. Unfortunately there is more then ~1000
> changed LOC. So not sure if this is the right approach to apply them.
> Not sure if the upgrade is acceptable.
>
> So how to proceed with this?
>
> I know, that they aren't a critical one, but would be nice to have them
> fixed.
>
> Regards,
> Andrej
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#178089): https://lists.openembedded.org/g/openembedded-core/message/178089
> Mute This Topic: https://lists.openembedded.org/mt/97444547/1686489
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [OE-core] [kirkstone] Google go CVEs

[Valek, Andrej]

Hello Alex,

Yes, that would an option, but afaik it wasn't working quite well. So I
would still prefer a straight forward solution.

Should I spend some time for creating such patches? Means if there will
be a potential option for being accepted?

Andrej

On Tue, 2023-03-07 at 07:37 +0100, Alexander Kanavin wrote:
> You probably should make a kirkstone mixin layer like we did for
> dunfell.
> https://git.yoctoproject.org/meta-lts-mixins/
> 
> Alex
> 
> On Tue, 7 Mar 2023 at 07:32, Andrej Valek <andrej.valek@siemens.com>
> wrote:
> > 
> > Hello everyone,
> > 
> > I would like to ask you how to proceed with multiple CVEs for
> > Google Go
> > component in kirkstone branch.
> > 
> > CVEs in current version 1.17.13:
> > - CVE-2022-41722
> > - CVE-2022-41725
> > - CVE-2022-41724
> > - CVE-2022-41723
> > 
> > They are fixed in 1.19.6/1.20.1 branches, but a fixing patches are
> > available for all of them too. Unfortunately there is more then
> > ~1000
> > changed LOC. So not sure if this is the right approach to apply
> > them.
> > Not sure if the upgrade is acceptable.
> > 
> > So how to proceed with this?
> > 
> > I know, that they aren't a critical one, but would be nice to have
> > them
> > fixed.
> > 
> > Regards,
> > Andrej
> > 
> > -=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> > View/Reply Online (#178089):
> > https://lists.openembedded.org/g/openembedded-core/message/178089
> > Mute This Topic: https://lists.openembedded.org/mt/97444547/1686489
> > Group Owner: openembedded-core+owner@lists.openembedded.org
> > Unsubscribe:
> > https://lists.openembedded.org/g/openembedded-core/unsub [
> > alex.kanavin@gmail.com]
> > -=-=-=-=-=-=-=-=-=-=-=-
> > 

Re: [OE-core] [kirkstone] Google go CVEs

[Alexander Kanavin]

If you understand the code well, and can be confident that your
backports address the issue correctly and do not introduce new issues,
then by all means go ahead.

My personal position should be known: I see the whole 'CVE
backporting' industry as a colossal waste. We need to learn to update
to supported upstream versions, and not be scared of breaking
production with that.

Alex

On Tue, 7 Mar 2023 at 10:05, Valek, Andrej <andrej.valek@siemens.com> wrote:
>
> Hello Alex,
>
> Yes, that would an option, but afaik it wasn't working quite well. So I
> would still prefer a straight forward solution.
>
> Should I spend some time for creating such patches? Means if there will
> be a potential option for being accepted?
>
> Andrej
>
> On Tue, 2023-03-07 at 07:37 +0100, Alexander Kanavin wrote:
> > You probably should make a kirkstone mixin layer like we did for
> > dunfell.
> > https://git.yoctoproject.org/meta-lts-mixins/
> >
> > Alex
> >
> > On Tue, 7 Mar 2023 at 07:32, Andrej Valek <andrej.valek@siemens.com>
> > wrote:
> > >
> > > Hello everyone,
> > >
> > > I would like to ask you how to proceed with multiple CVEs for
> > > Google Go
> > > component in kirkstone branch.
> > >
> > > CVEs in current version 1.17.13:
> > > - CVE-2022-41722
> > > - CVE-2022-41725
> > > - CVE-2022-41724
> > > - CVE-2022-41723
> > >
> > > They are fixed in 1.19.6/1.20.1 branches, but a fixing patches are
> > > available for all of them too. Unfortunately there is more then
> > > ~1000
> > > changed LOC. So not sure if this is the right approach to apply
> > > them.
> > > Not sure if the upgrade is acceptable.
> > >
> > > So how to proceed with this?
> > >
> > > I know, that they aren't a critical one, but would be nice to have
> > > them
> > > fixed.
> > >
> > > Regards,
> > > Andrej
> > >
> > > -=-=-=-=-=-=-=-=-=-=-=-
> > > Links: You receive all messages sent to this group.
> > > View/Reply Online (#178089):
> > > https://lists.openembedded.org/g/openembedded-core/message/178089
> > > Mute This Topic: https://lists.openembedded.org/mt/97444547/1686489
> > > Group Owner: openembedded-core+owner@lists.openembedded.org
> > > Unsubscribe:
> > > https://lists.openembedded.org/g/openembedded-core/unsub [
> > > alex.kanavin@gmail.com]
> > > -=-=-=-=-=-=-=-=-=-=-=-
> > >
>

Re: [OE-core] [kirkstone] Google go CVEs

[Jose Quaresma]

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

Hi,

At Foundries.io we intend to update the docker version on the kirkstone
branch to the latest available upstream, currently v23.
Looks like the better approach can be doing that in the mixin layer,
for that a new kirstone lts branch will be required.

This requires a golang update as well but the golang on master is broken
for some cases when -linkshared is in use and we are still debugging this
issue.
I pretend to start this backport when I can stabilize first the golang 1.20
on master.

Do you think this approach for updating docker is appropriate
and acceptable?

Jose


Alexander Kanavin <alex.kanavin@gmail.com> escreveu no dia terça, 7/03/2023
à(s) 09:34:

> If you understand the code well, and can be confident that your
> backports address the issue correctly and do not introduce new issues,
> then by all means go ahead.
>
> My personal position should be known: I see the whole 'CVE
> backporting' industry as a colossal waste. We need to learn to update
> to supported upstream versions, and not be scared of breaking
> production with that.
>
> Alex
>
> On Tue, 7 Mar 2023 at 10:05, Valek, Andrej <andrej.valek@siemens.com>
> wrote:
> >
> > Hello Alex,
> >
> > Yes, that would an option, but afaik it wasn't working quite well. So I
> > would still prefer a straight forward solution.
> >
> > Should I spend some time for creating such patches? Means if there will
> > be a potential option for being accepted?
> >
> > Andrej
> >
> > On Tue, 2023-03-07 at 07:37 +0100, Alexander Kanavin wrote:
> > > You probably should make a kirkstone mixin layer like we did for
> > > dunfell.
> > > https://git.yoctoproject.org/meta-lts-mixins/
> > >
> > > Alex
> > >
> > > On Tue, 7 Mar 2023 at 07:32, Andrej Valek <andrej.valek@siemens.com>
> > > wrote:
> > > >
> > > > Hello everyone,
> > > >
> > > > I would like to ask you how to proceed with multiple CVEs for
> > > > Google Go
> > > > component in kirkstone branch.
> > > >
> > > > CVEs in current version 1.17.13:
> > > > - CVE-2022-41722
> > > > - CVE-2022-41725
> > > > - CVE-2022-41724
> > > > - CVE-2022-41723
> > > >
> > > > They are fixed in 1.19.6/1.20.1 branches, but a fixing patches are
> > > > available for all of them too. Unfortunately there is more then
> > > > ~1000
> > > > changed LOC. So not sure if this is the right approach to apply
> > > > them.
> > > > Not sure if the upgrade is acceptable.
> > > >
> > > > So how to proceed with this?
> > > >
> > > > I know, that they aren't a critical one, but would be nice to have
> > > > them
> > > > fixed.
> > > >
> > > > Regards,
> > > > Andrej
> > > >
> > > >
> > > >
> >
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#178097):
> https://lists.openembedded.org/g/openembedded-core/message/178097
> Mute This Topic: https://lists.openembedded.org/mt/97444547/5052612
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
> quaresma.jose@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

-- 
Best regards,

José Quaresma

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

Re: [OE-core] [kirkstone] Google go CVEs

[Mikko Rapeli]

Hi,

On Tue, Mar 07, 2023 at 11:43:32AM +0000, Jose Quaresma wrote:
> Hi,
> 
> At Foundries.io we intend to update the docker version on the kirkstone
> branch to the latest available upstream, currently v23.
> Looks like the better approach can be doing that in the mixin layer,
> for that a new kirstone lts branch will be required.

FWIW, meta-virtualization master branch works well with kirkstone and
docker can be updated that way.

Many layers remove layer compatibility with older LTS releases even when
technically recipes still work, at least with very few exceptions.

> This requires a golang update as well but the golang on master is broken
> for some cases when -linkshared is in use and we are still debugging this
> issue.
> I pretend to start this backport when I can stabilize first the golang 1.20
> on master.

Cherry-picking go patches from poky master to kirkstone also works once
the kirkstone specific security updates have been reverted.

Even if Alex disagrees, CVE patch backporting is needed when SW
components break APIs and ABIs between releases. For mature and API/ABI
compatible SW components the updates are trivial, but even with them
there are exceptions and surprises.

I think yocto maintainers can make sensible decisions and compromises for SW
components and features which get updates vs which get CVE security patches. I
think many "development only" tools can also be updated quite freely
also in LTS branches. For example CVE and SPDX tooling, maybe even
bitbake itself, git, subversion etc. gcc and libc do break things on major updates, same for
clang. go, rust, perl, python have possibly more stable updates so those
could be aligned with all maintained branches. If no-one is posting CVE
patches for complex SW components to LTS branches then I'd update them
to latest release or even master branch rather than keep the affected
CVEs open for ever. If there are not enough maintainers/resources, then even
breaking the API compatibility is ok. nodejs, rust, go, webkit, tiff etc are
really pain to maintain and thus updating them to latest release should be
considered even if APIs change.

Cheers,

-Mikko

Re: [OE-core] [kirkstone] Google go CVEs

[Bruce Ashfield]

On Tue, Mar 7, 2023 at 7:15 AM Mikko Rapeli <mikko.rapeli@linaro.org> wrote:
>
> Hi,
>
> On Tue, Mar 07, 2023 at 11:43:32AM +0000, Jose Quaresma wrote:
> > Hi,
> >
> > At Foundries.io we intend to update the docker version on the kirkstone
> > branch to the latest available upstream, currently v23.
> > Looks like the better approach can be doing that in the mixin layer,
> > for that a new kirstone lts branch will be required.
>
> FWIW, meta-virtualization master branch works well with kirkstone and
> docker can be updated that way.

And I'm also happy to maintain multiple versions in the released
meta-virt branches, that way we can keep compatibility, but also offer
a newer version that can be selected by preferred version.

I'd rather have the main/supported recipes in the layers where most of
the effort is placed, versus spraying them around in mixin layers.

But as Mikko said, also consider just trying master against the
release, as chances are it is fine, and the branching is just to put a
stake in the ground for when the release happened.

Bruce

>
> Many layers remove layer compatibility with older LTS releases even when
> technically recipes still work, at least with very few exceptions.
>
> > This requires a golang update as well but the golang on master is broken
> > for some cases when -linkshared is in use and we are still debugging this
> > issue.
> > I pretend to start this backport when I can stabilize first the golang 1.20
> > on master.
>
> Cherry-picking go patches from poky master to kirkstone also works once
> the kirkstone specific security updates have been reverted.
>
> Even if Alex disagrees, CVE patch backporting is needed when SW
> components break APIs and ABIs between releases. For mature and API/ABI
> compatible SW components the updates are trivial, but even with them
> there are exceptions and surprises.
>
> I think yocto maintainers can make sensible decisions and compromises for SW
> components and features which get updates vs which get CVE security patches. I
> think many "development only" tools can also be updated quite freely
> also in LTS branches. For example CVE and SPDX tooling, maybe even
> bitbake itself, git, subversion etc. gcc and libc do break things on major updates, same for
> clang. go, rust, perl, python have possibly more stable updates so those
> could be aligned with all maintained branches. If no-one is posting CVE
> patches for complex SW components to LTS branches then I'd update them
> to latest release or even master branch rather than keep the affected
> CVEs open for ever. If there are not enough maintainers/resources, then even
> breaking the API compatibility is ok. nodejs, rust, go, webkit, tiff etc are
> really pain to maintain and thus updating them to latest release should be
> considered even if APIs change.
>
> Cheers,
>
> -Mikko
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#178105): https://lists.openembedded.org/g/openembedded-core/message/178105
> Mute This Topic: https://lists.openembedded.org/mt/97444547/1050810
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [bruce.ashfield@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Re: [OE-core] [kirkstone] Google go CVEs

[Jose Quaresma]

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

Bruce Ashfield <bruce.ashfield@gmail.com> escreveu no dia terça, 7/03/2023
à(s) 13:52:

> On Tue, Mar 7, 2023 at 7:15 AM Mikko Rapeli <mikko.rapeli@linaro.org>
> wrote:
> >
> > Hi,
> >
> > On Tue, Mar 07, 2023 at 11:43:32AM +0000, Jose Quaresma wrote:
> > > Hi,
> > >
> > > At Foundries.io we intend to update the docker version on the kirkstone
> > > branch to the latest available upstream, currently v23.
> > > Looks like the better approach can be doing that in the mixin layer,
> > > for that a new kirstone lts branch will be required.
> >
> > FWIW, meta-virtualization master branch works well with kirkstone and
> > docker can be updated that way.
>
> And I'm also happy to maintain multiple versions in the released
> meta-virt branches, that way we can keep compatibility, but also offer
> a newer version that can be selected by preferred version.
>
> I'd rather have the main/supported recipes in the layers where most of
> the effort is placed, versus spraying them around in mixin layers.
>
> But as Mikko said, also consider just trying master against the
> release, as chances are it is fine, and the branching is just to put a
> stake in the ground for when the release happened.
>

One of the problems with this approach of using the master branch of
meta-virt
is because some go recipes/projects require a recent version of the golang
to build the latest version.
At last the golang needs to be backported on the mixin layer to circumvent
these problems.

Anyway I will try to build oe-core kirkstone with meta-virt master branch
to get a better overview of the build requirements.

Jose


>
> Bruce
>
> >
> > Many layers remove layer compatibility with older LTS releases even when
> > technically recipes still work, at least with very few exceptions.
> >
> > > This requires a golang update as well but the golang on master is
> broken
> > > for some cases when -linkshared is in use and we are still debugging
> this
> > > issue.
> > > I pretend to start this backport when I can stabilize first the golang
> 1.20
> > > on master.
> >
> > Cherry-picking go patches from poky master to kirkstone also works once
> > the kirkstone specific security updates have been reverted.
> >
> > Even if Alex disagrees, CVE patch backporting is needed when SW
> > components break APIs and ABIs between releases. For mature and API/ABI
> > compatible SW components the updates are trivial, but even with them
> > there are exceptions and surprises.
> >
> > I think yocto maintainers can make sensible decisions and compromises
> for SW
> > components and features which get updates vs which get CVE security
> patches. I
> > think many "development only" tools can also be updated quite freely
> > also in LTS branches. For example CVE and SPDX tooling, maybe even
> > bitbake itself, git, subversion etc. gcc and libc do break things on
> major updates, same for
> > clang. go, rust, perl, python have possibly more stable updates so those
> > could be aligned with all maintained branches. If no-one is posting CVE
> > patches for complex SW components to LTS branches then I'd update them
> > to latest release or even master branch rather than keep the affected
> > CVEs open for ever. If there are not enough maintainers/resources, then
> even
> > breaking the API compatibility is ok. nodejs, rust, go, webkit, tiff etc
> are
> > really pain to maintain and thus updating them to latest release should
> be
> > considered even if APIs change.
> >
> > Cheers,
> >
> > -Mikko
> >
> > -=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> > View/Reply Online (#178105):
> https://lists.openembedded.org/g/openembedded-core/message/178105
> > Mute This Topic: https://lists.openembedded.org/mt/97444547/1050810
> > Group Owner: openembedded-core+owner@lists.openembedded.org
> > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
> bruce.ashfield@gmail.com]
> > -=-=-=-=-=-=-=-=-=-=-=-
> >
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>


-- 
Best regards,

José Quaresma

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

Re: [OE-core] [kirkstone] Google go CVEs

[Bruce Ashfield]

On Tue, Mar 7, 2023 at 9:58 AM Jose Quaresma <quaresma.jose@gmail.com> wrote:
>
>
>
> Bruce Ashfield <bruce.ashfield@gmail.com> escreveu no dia terça, 7/03/2023 à(s) 13:52:
>>
>> On Tue, Mar 7, 2023 at 7:15 AM Mikko Rapeli <mikko.rapeli@linaro.org> wrote:
>> >
>> > Hi,
>> >
>> > On Tue, Mar 07, 2023 at 11:43:32AM +0000, Jose Quaresma wrote:
>> > > Hi,
>> > >
>> > > At Foundries.io we intend to update the docker version on the kirkstone
>> > > branch to the latest available upstream, currently v23.
>> > > Looks like the better approach can be doing that in the mixin layer,
>> > > for that a new kirstone lts branch will be required.
>> >
>> > FWIW, meta-virtualization master branch works well with kirkstone and
>> > docker can be updated that way.
>>
>> And I'm also happy to maintain multiple versions in the released
>> meta-virt branches, that way we can keep compatibility, but also offer
>> a newer version that can be selected by preferred version.
>>
>> I'd rather have the main/supported recipes in the layers where most of
>> the effort is placed, versus spraying them around in mixin layers.
>>
>> But as Mikko said, also consider just trying master against the
>> release, as chances are it is fine, and the branching is just to put a
>> stake in the ground for when the release happened.
>
>
> One of the problems with this approach of using the master branch of meta-virt
> is because some go recipes/projects require a recent version of the golang to build the latest version.
> At last the golang needs to be backported on the mixin layer to circumvent these problems.

Right. You may still need some sort of mixin layer (for go, etc), I'm
more saying that I would be willing to get whatever version of
meta-virt tools available in the appropriate branches, since it
doesn't mean a forced upgrade to all users if we just keep the
multiple versions around.

Bruce

>
> Anyway I will try to build oe-core kirkstone with meta-virt master branch
> to get a better overview of the build requirements.
>
> Jose
>
>>
>>
>> Bruce
>>
>> >
>> > Many layers remove layer compatibility with older LTS releases even when
>> > technically recipes still work, at least with very few exceptions.
>> >
>> > > This requires a golang update as well but the golang on master is broken
>> > > for some cases when -linkshared is in use and we are still debugging this
>> > > issue.
>> > > I pretend to start this backport when I can stabilize first the golang 1.20
>> > > on master.
>> >
>> > Cherry-picking go patches from poky master to kirkstone also works once
>> > the kirkstone specific security updates have been reverted.
>> >
>> > Even if Alex disagrees, CVE patch backporting is needed when SW
>> > components break APIs and ABIs between releases. For mature and API/ABI
>> > compatible SW components the updates are trivial, but even with them
>> > there are exceptions and surprises.
>> >
>> > I think yocto maintainers can make sensible decisions and compromises for SW
>> > components and features which get updates vs which get CVE security patches. I
>> > think many "development only" tools can also be updated quite freely
>> > also in LTS branches. For example CVE and SPDX tooling, maybe even
>> > bitbake itself, git, subversion etc. gcc and libc do break things on major updates, same for
>> > clang. go, rust, perl, python have possibly more stable updates so those
>> > could be aligned with all maintained branches. If no-one is posting CVE
>> > patches for complex SW components to LTS branches then I'd update them
>> > to latest release or even master branch rather than keep the affected
>> > CVEs open for ever. If there are not enough maintainers/resources, then even
>> > breaking the API compatibility is ok. nodejs, rust, go, webkit, tiff etc are
>> > really pain to maintain and thus updating them to latest release should be
>> > considered even if APIs change.
>> >
>> > Cheers,
>> >
>> > -Mikko
>> >
>> > -=-=-=-=-=-=-=-=-=-=-=-
>> > Links: You receive all messages sent to this group.
>> > View/Reply Online (#178105): https://lists.openembedded.org/g/openembedded-core/message/178105
>> > Mute This Topic: https://lists.openembedded.org/mt/97444547/1050810
>> > Group Owner: openembedded-core+owner@lists.openembedded.org
>> > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [bruce.ashfield@gmail.com]
>> > -=-=-=-=-=-=-=-=-=-=-=-
>> >
>>
>>
>> --
>> - Thou shalt not follow the NULL pointer, for chaos and madness await
>> thee at its end
>> - "Use the force Harry" - Gandalf, Star Trek II
>
>
>
> --
> Best regards,
>
> José Quaresma



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Re: [OE-core] [kirkstone] Google go CVEs

[Jose Quaresma]

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

Bruce Ashfield <bruce.ashfield@gmail.com> escreveu no dia terça, 7/03/2023
à(s) 15:15:

> On Tue, Mar 7, 2023 at 9:58 AM Jose Quaresma <quaresma.jose@gmail.com>
> wrote:
> >
> >
> >
> > Bruce Ashfield <bruce.ashfield@gmail.com> escreveu no dia terça,
> 7/03/2023 à(s) 13:52:
> >>
> >> On Tue, Mar 7, 2023 at 7:15 AM Mikko Rapeli <mikko.rapeli@linaro.org>
> wrote:
> >> >
> >> > Hi,
> >> >
> >> > On Tue, Mar 07, 2023 at 11:43:32AM +0000, Jose Quaresma wrote:
> >> > > Hi,
> >> > >
> >> > > At Foundries.io we intend to update the docker version on the
> kirkstone
> >> > > branch to the latest available upstream, currently v23.
> >> > > Looks like the better approach can be doing that in the mixin layer,
> >> > > for that a new kirstone lts branch will be required.
> >> >
> >> > FWIW, meta-virtualization master branch works well with kirkstone and
> >> > docker can be updated that way.
> >>
> >> And I'm also happy to maintain multiple versions in the released
> >> meta-virt branches, that way we can keep compatibility, but also offer
> >> a newer version that can be selected by preferred version.
> >>
> >> I'd rather have the main/supported recipes in the layers where most of
> >> the effort is placed, versus spraying them around in mixin layers.
> >>
> >> But as Mikko said, also consider just trying master against the
> >> release, as chances are it is fine, and the branching is just to put a
> >> stake in the ground for when the release happened.
> >
> >
> > One of the problems with this approach of using the master branch of
> meta-virt
> > is because some go recipes/projects require a recent version of the
> golang to build the latest version.
> > At last the golang needs to be backported on the mixin layer to
> circumvent these problems.
>
> Right. You may still need some sort of mixin layer (for go, etc), I'm
> more saying that I would be willing to get whatever version of
> meta-virt tools available in the appropriate branches, since it
> doesn't mean a forced upgrade to all users if we just keep the
> multiple versions around.
>

Having on meta-virt more than one version available on the stable/lts
branches
looks like a great improvement. The newest version can use
default_prefference -1
so we can maintain some type of abi/api stabilization enabled by default.

However it will always be difficult to decide which version of golang the
tool on meta-virt needs.
And of course, the adicional maintenance overhead can increase a lot.

Jose


> Bruce
>
> >
> > Anyway I will try to build oe-core kirkstone with meta-virt master branch
> > to get a better overview of the build requirements.
> >
> > Jose
> >
> >>
> >>
> >> Bruce
> >>
> >> >
> >> > Many layers remove layer compatibility with older LTS releases even
> when
> >> > technically recipes still work, at least with very few exceptions.
> >> >
> >> > > This requires a golang update as well but the golang on master is
> broken
> >> > > for some cases when -linkshared is in use and we are still
> debugging this
> >> > > issue.
> >> > > I pretend to start this backport when I can stabilize first the
> golang 1.20
> >> > > on master.
> >> >
> >> > Cherry-picking go patches from poky master to kirkstone also works
> once
> >> > the kirkstone specific security updates have been reverted.
> >> >
> >> > Even if Alex disagrees, CVE patch backporting is needed when SW
> >> > components break APIs and ABIs between releases. For mature and
> API/ABI
> >> > compatible SW components the updates are trivial, but even with them
> >> > there are exceptions and surprises.
> >> >
> >> > I think yocto maintainers can make sensible decisions and compromises
> for SW
> >> > components and features which get updates vs which get CVE security
> patches. I
> >> > think many "development only" tools can also be updated quite freely
> >> > also in LTS branches. For example CVE and SPDX tooling, maybe even
> >> > bitbake itself, git, subversion etc. gcc and libc do break things on
> major updates, same for
> >> > clang. go, rust, perl, python have possibly more stable updates so
> those
> >> > could be aligned with all maintained branches. If no-one is posting
> CVE
> >> > patches for complex SW components to LTS branches then I'd update them
> >> > to latest release or even master branch rather than keep the affected
> >> > CVEs open for ever. If there are not enough maintainers/resources,
> then even
> >> > breaking the API compatibility is ok. nodejs, rust, go, webkit, tiff
> etc are
> >> > really pain to maintain and thus updating them to latest release
> should be
> >> > considered even if APIs change.
> >> >
> >> > Cheers,
> >> >
> >> > -Mikko
> >> >
> >> > -=-=-=-=-=-=-=-=-=-=-=-
> >> > Links: You receive all messages sent to this group.
> >> > View/Reply Online (#178105):
> https://lists.openembedded.org/g/openembedded-core/message/178105
> >> > Mute This Topic: https://lists.openembedded.org/mt/97444547/1050810
> >> > Group Owner: openembedded-core+owner@lists.openembedded.org
> >> > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
> [bruce.ashfield@gmail.com]
> >> > -=-=-=-=-=-=-=-=-=-=-=-
> >> >
> >>
> >>
> >> --
> >> - Thou shalt not follow the NULL pointer, for chaos and madness await
> >> thee at its end
> >> - "Use the force Harry" - Gandalf, Star Trek II
> >
> >
> >
> > --
> > Best regards,
> >
> > José Quaresma
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>


-- 
Best regards,

José Quaresma

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

Re: [OE-core] [kirkstone] Google go CVEs

[Bruce Ashfield]

On Tue, Mar 7, 2023 at 10:48 AM Jose Quaresma <quaresma.jose@gmail.com> wrote:
>
>
>
> Bruce Ashfield <bruce.ashfield@gmail.com> escreveu no dia terça, 7/03/2023 à(s) 15:15:
>>
>> On Tue, Mar 7, 2023 at 9:58 AM Jose Quaresma <quaresma.jose@gmail.com> wrote:
>> >
>> >
>> >
>> > Bruce Ashfield <bruce.ashfield@gmail.com> escreveu no dia terça, 7/03/2023 à(s) 13:52:
>> >>
>> >> On Tue, Mar 7, 2023 at 7:15 AM Mikko Rapeli <mikko.rapeli@linaro.org> wrote:
>> >> >
>> >> > Hi,
>> >> >
>> >> > On Tue, Mar 07, 2023 at 11:43:32AM +0000, Jose Quaresma wrote:
>> >> > > Hi,
>> >> > >
>> >> > > At Foundries.io we intend to update the docker version on the kirkstone
>> >> > > branch to the latest available upstream, currently v23.
>> >> > > Looks like the better approach can be doing that in the mixin layer,
>> >> > > for that a new kirstone lts branch will be required.
>> >> >
>> >> > FWIW, meta-virtualization master branch works well with kirkstone and
>> >> > docker can be updated that way.
>> >>
>> >> And I'm also happy to maintain multiple versions in the released
>> >> meta-virt branches, that way we can keep compatibility, but also offer
>> >> a newer version that can be selected by preferred version.
>> >>
>> >> I'd rather have the main/supported recipes in the layers where most of
>> >> the effort is placed, versus spraying them around in mixin layers.
>> >>
>> >> But as Mikko said, also consider just trying master against the
>> >> release, as chances are it is fine, and the branching is just to put a
>> >> stake in the ground for when the release happened.
>> >
>> >
>> > One of the problems with this approach of using the master branch of meta-virt
>> > is because some go recipes/projects require a recent version of the golang to build the latest version.
>> > At last the golang needs to be backported on the mixin layer to circumvent these problems.
>>
>> Right. You may still need some sort of mixin layer (for go, etc), I'm
>> more saying that I would be willing to get whatever version of
>> meta-virt tools available in the appropriate branches, since it
>> doesn't mean a forced upgrade to all users if we just keep the
>> multiple versions around.
>
>
> Having on meta-virt more than one version available on the stable/lts branches
> looks like a great improvement. The newest version can use default_prefference -1
> so we can maintain some type of abi/api stabilization enabled by default.
>
> However it will always be difficult to decide which version of golang the tool on meta-virt needs.
> And of course, the adicional maintenance overhead can increase a lot.

Having battled the go applications in meta-virt for a long time now,
it really isn't all that often we have issues with golang versions, in
the sense of needing matched versions. It is normally new features
that are required, versus a new golang dropping features. So a newer
go has almost always worked for all the versions we need.

The extra maintenance isn't significant, in particular when balanced
around trying to keep a centre of gravity around the recipes.

Bruce

>
> Jose
>
>>
>> Bruce
>>
>> >
>> > Anyway I will try to build oe-core kirkstone with meta-virt master branch
>> > to get a better overview of the build requirements.
>> >
>> > Jose
>> >
>> >>
>> >>
>> >> Bruce
>> >>
>> >> >
>> >> > Many layers remove layer compatibility with older LTS releases even when
>> >> > technically recipes still work, at least with very few exceptions.
>> >> >
>> >> > > This requires a golang update as well but the golang on master is broken
>> >> > > for some cases when -linkshared is in use and we are still debugging this
>> >> > > issue.
>> >> > > I pretend to start this backport when I can stabilize first the golang 1.20
>> >> > > on master.
>> >> >
>> >> > Cherry-picking go patches from poky master to kirkstone also works once
>> >> > the kirkstone specific security updates have been reverted.
>> >> >
>> >> > Even if Alex disagrees, CVE patch backporting is needed when SW
>> >> > components break APIs and ABIs between releases. For mature and API/ABI
>> >> > compatible SW components the updates are trivial, but even with them
>> >> > there are exceptions and surprises.
>> >> >
>> >> > I think yocto maintainers can make sensible decisions and compromises for SW
>> >> > components and features which get updates vs which get CVE security patches. I
>> >> > think many "development only" tools can also be updated quite freely
>> >> > also in LTS branches. For example CVE and SPDX tooling, maybe even
>> >> > bitbake itself, git, subversion etc. gcc and libc do break things on major updates, same for
>> >> > clang. go, rust, perl, python have possibly more stable updates so those
>> >> > could be aligned with all maintained branches. If no-one is posting CVE
>> >> > patches for complex SW components to LTS branches then I'd update them
>> >> > to latest release or even master branch rather than keep the affected
>> >> > CVEs open for ever. If there are not enough maintainers/resources, then even
>> >> > breaking the API compatibility is ok. nodejs, rust, go, webkit, tiff etc are
>> >> > really pain to maintain and thus updating them to latest release should be
>> >> > considered even if APIs change.
>> >> >
>> >> > Cheers,
>> >> >
>> >> > -Mikko
>> >> >
>> >> > -=-=-=-=-=-=-=-=-=-=-=-
>> >> > Links: You receive all messages sent to this group.
>> >> > View/Reply Online (#178105): https://lists.openembedded.org/g/openembedded-core/message/178105
>> >> > Mute This Topic: https://lists.openembedded.org/mt/97444547/1050810
>> >> > Group Owner: openembedded-core+owner@lists.openembedded.org
>> >> > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [bruce.ashfield@gmail.com]
>> >> > -=-=-=-=-=-=-=-=-=-=-=-
>> >> >
>> >>
>> >>
>> >> --
>> >> - Thou shalt not follow the NULL pointer, for chaos and madness await
>> >> thee at its end
>> >> - "Use the force Harry" - Gandalf, Star Trek II
>> >
>> >
>> >
>> > --
>> > Best regards,
>> >
>> > José Quaresma
>>
>>
>>
>> --
>> - Thou shalt not follow the NULL pointer, for chaos and madness await
>> thee at its end
>> - "Use the force Harry" - Gandalf, Star Trek II
>
>
>
> --
> Best regards,
>
> José Quaresma



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Re: [OE-core] [kirkstone] Google go CVEs

[Freihofer, Adrian]

Hi,

From my perspective, the challenge (and also the original question of
this thread) is the short lifecycle of the newer language stacks,
namely Golang and Rust. Security patches are not provided by the go
community for the entire LTS period of Yocto. Golang practices are
partially at odds with the idea of a LTS distro. It's not only about
Docker or other components, it's also about the go tool-chain itself
which provides a ~50MB library (with vulnarabilities) which gets linked
(usually statically and stripped) by all go applications.

When we were still on the Dunfell branch, we had tried to solve the
issue with the mixin repo from
https://git.yoctoproject.org/meta-lts-mixins/refs/. But it didn't
really work well. The mixin layer brings the latest go stack from poky
master back to poky dunfell. Since there are no go recipes in poky so
far, this works relatively easily. But adding this layer more or less
breaks all recipes from meta-virtualization. A mixin layer which
updates the main go tool-chain does not look like a generic and easy
maintainable approach.

On the other hand, Golang and Rust are much more self-contained than
other language stacks, which in turn makes it relatively easy to
install more than one Golang version in parallel on a host and to use
one or the other Golang version depending on the software to be
compiled. The development approaches of most go-based software
components are also based on this assumption. Docker 21, for example,
had required go 1.17 and then switched to go 1.18. At least my
conclusion was that the switch to golang 1.18 must be reverted to allow
compiling the latest Docker 21 with golang 1.17 from poky. See
https://git.yoctoproject.org/meta-virtualization/commit/?h=kirkstone&id=927537108bcf2b98859512ce3eae59a73439994d
. This means that as long as there is only one go version available
with poky, updating or maintaining multiple version of go based recipes
is only possible for some recipes and comes with additional effort per
recipe.

My conclusion so far is that the most generic and probably also the
most straight forward approach would be to support more than one go
(and probably also rust) version for the LTS branches. If recipes could
choose the go-native version for example meta-virtualization could
offer e.g. Docker 21 with DEPENDS += "go-native" and also Docker 23
with DEPENDS += "go-1-19-native". Please note that I'm thinking about
different go-native recipes with the major version of go in the recipe
name not about different go-native recipe versions. This would allow to
make them concurently available. Additional go versions could be
provided by poky or by a mixin layer.

This approach would make it possible to keep go recipes more up-to-date
and thus also fix security vulnerabilities without having to backport
many patches to many go-dependent recipes. This would probably be ideal
for meta-virtualization (especially if multiple versions should be
supported for certain recipes) as well as for many practical scenarios.

But at least in the first place it would not help to improve the
situation of open CVEs in upstream unmaintained go tool-chains which
are still used by poky LTS. Backported patches would still be needed to
keep poky itself secure and get nice CVE metrics for poky world builds
until older tool-chains would be replaced or at least somehow
deprecated on the LTS branches.

Regards Adrian