Hello Deepak,

Some components are just not suitable for LTS maintenance because they evolve 
too fast during 4 year of Yocto LTS release lifetime.
This includes things like rust, browsers or anything which is built via go like 
containerization engines.
Golang itself does not contain many breaking changes, however apps using golang 
start using its new features very fast.

For exactly this reason meta-lts-mixins exists.
You don’t have to do anything for golang, it’s already there (both kirkstone 
and scarthgap with 1.25.7 and I’m going to update at least scarthgap to 1.26.0 
within a week or two).
You could submit a lts-mixins branch for virtualization components via 
yocto-patches mailing list, however it’s just so easy to use core/scarthgap + 
lts-mixins/go + virtualization/master.

So, it really depends on what is your goal.
My preference is to use core LTS + latest and greatest 
go/rust/virtualization/browser as that provides a good compromise between 
overall base library stability (for custom apps) and security (for exposed OSS 
components).
Upgrade via meta-lts-mixins needs a patch submission and maintainer for the new 
branch, which is usually the submitter.
Upgrade in core would need TSC approval, so you would need to submit a detailed 
plan including how to deal with possible incompatibilities.

Only very few components (vim as one of them) are allowed to be upgraded freely 
in LTS. And with new LTS maintainer, maybe also that won’t happen anymore, 
let’s see.
glibc/gnupg/libssh2 were only upgraded to stable their patch releases according 
to LTS rules, not further.
You can check following accepted proposal to TSC for backport of spdx3 to 
scarthgap: 
https://lists.openembedded.org/g/openembedded-architecture/message/2177
Also the ca-certificates were accepted by TSC (I don’t have link to that 
proposal, sorry).

Best Regards,
  Peter


From: Deepak Rathore -X (deeratho - E INFOCHIPS PRIVATE LIMITED at Cisco) 
<[email protected]>
Sent: Tuesday, February 17, 2026 13:49
To: Marko, Peter (FT D EU SK BFS1) <[email protected]>; Jose Quaresma 
<[email protected]>
Cc: Khem Raj <[email protected]>; Viral Chavda (vchavda) <[email protected]>; 
[email protected]; Ruslan Bilovol (rbilovol) 
<[email protected]>
Subject: Re: [OE-core] Clarification on handling recent CVEs for 
go-binary-native package

Hello Peter and Jose,
Thank you for your responses regarding the reported issues.
I would like to confirm that all the CVEs mentioned are indeed applicable to 
our project, as well as to any setup that enables these vulnerable packages. 
Our Yocto source is closely aligned with the upstream Yocto repository, and we 
regularly sync with the community. We have been addressing CVEs for the 
packages from community and upstreaming fixes whenever possible.
However, we have observed that the go-binary-native recipe depends on a 
prebuilt binary instead of building Go from source, which prevents us from 
applying CVE patches directly.
We are facing similar challenges with runc package in the meta-virtualization 
layer where backporting CVE fixes to the Scarthgap LTS version is not feasible 
due to significant upstream code changes. In such cases, we believe that 
upgrading the package version is the most practical and maintainable solution. 
We also want to ensure that the upstream LTS branches are not left vulnerable, 
so we are preparing to upstream our fixes to the community.
We have noticed several other recent upgrade requests in the community (e.g., 
glibc, gnupg, libssh2, vim), so in the same spirit, we have prepared upgrade 
patches to address the CVEs for both runc-opencontainers and go-binary-native:

  *   Go: v1.22.12 → v1.24.0
  *   runc: v1.1.14 → v1.3.0
We would like to contribute these upgrade patches to the appropriate layers. 
Could you please advise whether submitting these upgrades is appropriate in 
this scenario, and if so, what the recommended process would be?
Looking forward to your guidance.
Thank you,
Deepak
________________________________
From: Marko, Peter <[email protected]<mailto:[email protected]>>
Sent: Friday, February 13, 2026 3:26 AM
To: Jose Quaresma <[email protected]<mailto:[email protected]>>; 
Deepak Rathore -X (deeratho - E INFOCHIPS PRIVATE LIMITED at Cisco) 
<[email protected]<mailto:[email protected]>>
Cc: Khem Raj <[email protected]<mailto:[email protected]>>; Viral Chavda 
(vchavda) <[email protected]<mailto:[email protected]>>; 
[email protected]<mailto:[email protected]>
 
<[email protected]<mailto:[email protected]>>
Subject: RE: [OE-core] Clarification on handling recent CVEs for 
go-binary-native package


Upstream (go.dev) will not help us, they have 6 months LTS policy compared to 
Yocto with 4 years.



This is a usual problem for LTS distributions, there are always some open CVEs 
where backporting fixes is too difficult or even impossible.

go-binary-native is unfortunately one of these cases where fixing CVEs is 
impractical.

It would require us to change go toolchain bootstrapping (without any clear 
vision how) or to generate precompiled binaries ourselves.



Question is if there is any practical attack possible on Yocto go toolchain 
bootstrapping process or if someone has native go recipes where it would also 
be used.

If you are worried about this for your project, meta-lts-mixins is probably the 
easiest way how to get rid of these CVEs from your vulnerability reports.

Or to use current Yocto release instead of LTS which with increase age always 
gather unfixed CVEs.



Peter



From: Jose Quaresma <[email protected]<mailto:[email protected]>>
Sent: Thursday, February 12, 2026 19:06
To: [email protected]<mailto:[email protected]>
Cc: Khem Raj <[email protected]<mailto:[email protected]>>; Viral Chavda 
(vchavda) <[email protected]<mailto:[email protected]>>; 
[email protected]<mailto:[email protected]>;
 Marko, Peter (FT D EU SK BFS1) 
<[email protected]<mailto:[email protected]>>
Subject: Re: [OE-core] Clarification on handling recent CVEs for 
go-binary-native package



Hi Deepak,



The go-binary-native was used to bootstrap the go toolchain, we take it from 
the official go upstream https://go.dev/dl.
Perhaps this is the ideal place to report such problems, so that they can 
create new binary packages with the referred CVE fixed.



Jose

Deepak Rathore via lists.openembedded.org<http://lists.openembedded.org> 
<[email protected]<mailto:[email protected]>>
 escreveu (quinta, 12/02/2026 à(s) 11:15):

Hello Khem Raj,



Several new CVEs have been assigned to go-binary-native package (as listed 
below). Based on the recipe, it’s been observed that it uses prebuilt instead 
of being built from source code. Can you please help to understand the 
procedures and how we can address applicable CVEs for these packages? Do we 
have any identified plan to address it?

CVEs affecting go-binary-native:

1.         CVE-2025-4674 (CVSS 8.6) – 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2025-4674

  1.  CVE-2025-47906 (CVSS 6.5) – 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2025-47906
  2.  CVE-2025-47907 (CVSS 7.0) –  
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2025-47907
  3.  CVE-2025-47912 (CVSS 5.3) – 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2025-47912
  4.  CVE-2025-58185 (CVSS 5.3) – 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2025-58185
  5.  CVE-2025-58187 (CVSS 7.5) – 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2025-58187
  6.  CVE-2025-58188 (CVSS 7.5) – 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2025-58188
  7.  CVE-2025-58189 (CVSS 5.3) – 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2025-58189
  8.  CVE-2025-61723 (CVSS 7.5) – 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2025-61723
  9.  CVE-2025-61724 (CVSS 5.3) – 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2025-61724
  10. CVE-2025-61726 (CVSS 7.5) – 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2025-61726
  11. CVE-2025-61727 (CVSS 6.5) – 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2025-61727
  12. CVE-2025-61728 (CVSS 6.5) – 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2025-61728
  13. CVE-2025-61729 (CVSS 7.5) – 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2025-61729
  14. CVE-2025-61730 (CVSS 5.3) – 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2025-61730
  15. CVE-2025-61731 (CVSS 7.8) – 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2025-61731
  16. CVE-2025-68119 (CVSS 7.0) – 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2025-68119
  17. CVE-2025-22873 (CVSS3: 3.8) - 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2025-22873
  18. CVE-2025-61732 (CVSS3: 8.6) - 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2025-61732
  19. CVE-2025-68121 (CVSS3: 10.0) - 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2025-68121

Thanks for the guidance.

Regards,
Deepak Rathore









--

Best regards,

José Quaresma
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#231256): 
https://lists.openembedded.org/g/openembedded-core/message/231256
Mute This Topic: https://lists.openembedded.org/mt/117772424/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to