On Tue, Jan 17, 2023 at 12:00 PM Alexander Kanavin <[email protected]> wrote: > > 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?
According to the stable release "rules" option 1 would require an exception granted by the TSC. Otherwise it is a no go. So it seems to me that this is a classic case for using a mix-in layer. Steve > 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 (#176065): https://lists.openembedded.org/g/openembedded-core/message/176065 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]] -=-=-=-=-=-=-=-=-=-=-=-
