Option 1 looks like a new policy too. If we can upgrade rust across many major versions in a stable release, then why not other items?
Alex On Tue, 17 Jan 2023 at 22:57, Randy MacLeod <[email protected]> wrote: > > On 2023-01-17 16:54, Richard Purdie wrote: > > On Tue, 2023-01-17 at 15:29 -0500, Randy MacLeod wrote: > >> On 2023-01-16 10:20, Kokkonda, Sundeep via lists.openembedded.org > >> wrote: > >> > >>> Rust community said the security fixes are only for the current > >>> stable relases. > >>> > >>> https://internals.rust-lang.org/t/cargo-cve-2022-46176-fix-for-older > >>> -releases/18152/3?u=sundeep-kokkonda > >>> For old release we've to backport the patches ourselves. > >> The other alternatives are > >> 1. upgrade to 1.66.1 on older branches, > >> 2. add 1.66.1, which will be the PREFERRED_VERSION but keep the older > >> version for those who are risk averse, > >> 3. add a mix-in layer (1) with the upgrade to 1.66.1. > >> For langdale, we'd update from 1.63 and for kirkstone, we'd update > >> from 1.59 > >> See the link above for a discussion about what Fedora/RHEL and other > >> distros are doing > >> and a description of the rust / crates.io test system known as > >> crater that builds the > >> world for any significant rust change. > >> > >> Is there any objection to doing 2 and if we don't see any problems > >> after some time, > >> then removing the older version? > >> Sundeep, > >> If no one object, please update kirkstone and see if librsvg or > >> python-cryptography or > >> anything else encounters a problem. > > > > I'm afraid I don't like option 2. We don't do this for anything else so > > we're now inventing some new policy. Either the upgrade is what we > > decide is right or it isn't, I don't really like the idea of hedging > > our bets and providing two versions, one of which nobody will use until > > they're forced. It will also make security scans tricky as is the issue > > dealt with or not? > > > > Just for context, going back in time OE used to be awash with many > > version of recipes and I'm reluctant to go back there as it was > > horrible. They were added for exactly this kind of reasoning, which at > > first seemed like a good idea. > > Okay, make sense, option 1 it is! > > ../Randy > > > > Cheers, > > > > Richard > > > > > > -- > # Randy MacLeod > # Wind River Linux > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#176064): https://lists.openembedded.org/g/openembedded-core/message/176064 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]] -=-=-=-=-=-=-=-=-=-=-=-
