On Wed, Jan 18, 2023 at 8:08 AM Mikko Rapeli <[email protected]> wrote: > > Hi, > > On Wed, Jan 18, 2023 at 08:45:56AM +0100, Alexander Kanavin wrote: > > On Wed, 18 Jan 2023 at 03:08, Randy MacLeod <[email protected]> > > 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.
We've been running with rust in production for a couple of years, I think we hit our first instance of an upgrade issue last week - a ureq crate upgrade changed something (I suspect in its pooling code) which meant that we ended up using all file descriptors. Wasn't caught in CI as nothing ran for long enough, but was caught in test (we still need to get to the root cause - right now we just rolled back that crate). But over that time we've aggressively upgraded rust from something like 1.48 to 1.66.1, all the crates we build against and to the best of my knowledge this is the first time we've been tripped up. > > 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. > For vendor reasons, we're stuck on thud (I know...), however we've a pile of backports so we can mostly just pick current recipes out of master or stable branches (python packages are the one which we're coming up against now as a blocker - fortunately we've expunged python from our target code base). My view for a very long time has been that you basically have to stay very close to the most current release of whatever upstream code you're consuming, otherwise you're doomed to spending more and more of your life finding/fixing issues (security or otherwise) which were long since addressed upstream. -- Alex Kiernan
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#176084): https://lists.openembedded.org/g/openembedded-core/message/176084 Mute This Topic: https://lists.openembedded.org/mt/96218038/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
