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