Hi, On Wed, Jan 18, 2023 at 08:45:56AM +0100, Alexander Kanavin wrote: > On Wed, 18 Jan 2023 at 03:08, Randy MacLeod <randy.macl...@windriver.com> > wrote: > > So far, there haven't been many Rust/Cargo CVEs so maybe we're making > > too big a deal out of this. I certainly don't miss the deluge of memory > > management CVEs that > > C/C++ applications suffer from! > > For what it's worth I'm with you here, and I actually have an even > more radical view (that may offend some - apologies). I think this > whole 'CVE backporting' business is both enormously wasteful and never > complete (or even close to it). Backporting CVEs and the stable > release policy is basically a cover-up for bad (or altogether absent) > CI at the project users side. If you upgrade a component, and it > causes trouble, the trouble should be caught by pipeline, and not in > the end product when the update has shipped.
It's usually not lack of CI, continuous integration, but lack of testing coverage which is visible as risk management where any changes are avoided and someties FUD replaces hard facts. A CI run may not show that SW compatibility or some use cases are broken. In the worst case this is detected by customers after SW has been deployed in the field. > The saner policy would have been 'a Yocto stable release contains > component versions all within their support windows by respective > upstreams'. If the only supported version is the latest one, then so > be it. When mainting yocto SW stack for a long time, I made the distinction between development tools and target SW. Basically all -native and nativesdk- recipes and those target recipes which are not in the product by default are development tools. Development tools can be updated to new versions to fix severe bugs and CVEs. For target SW, this can be done if ABI compatibility is preserved, or in case of severe issues where ABI is part of the problem or backporting the fix is more risky than an update, but this requires a managed transition with the product platform where all users of the SW are checked. ABI compatibility is important because frequently real products often need to integrate binaries where source code is not available to the bitbake build. With this approach, I've updated tools and compiler versions. I would not mind similar policy in upstream. Maintaining multiple rust/cargo versions well is not likely going to happen so I'd accept this and accept same updates in all branches. If the same tool version works well and is tested in another yocto branch and there are no major issues porting the same changes to another LTS branch, this gives confidence that the update is ok. Cheers, -Mikko
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#176077): https://lists.openembedded.org/g/openembedded-core/message/176077 Mute This Topic: https://lists.openembedded.org/mt/96218038/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
