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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#178146): https://lists.openembedded.org/g/openembedded-core/message/178146 Mute This Topic: https://lists.openembedded.org/mt/97444547/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
