On 2023-01-17 17:37, Steve Sakoman wrote:
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?
In oe-core we have a trivial exception for vim but of course it's an
application not a toolchain.
Similarly, in other layers, applications such as Chromium (and
Tensorflow?) only maintain one version and
users are expected to upgrade to get bug fixes.
The Rust developers / community seems to want their software to work in
a similar way.
They have a quite exhaustive test suite (Crater) to check for regressions.
I'll look for some actual test results from Crater and reply here when I
find them.
I not sure what to make of the "Rust Editions" and how they'd fit into
our distro support
but the clear mandate from upstream is that only the 'stable' release is
supported.
https://doc.rust-lang.org/edition-guide/editions/index.html
I think there's an argument to be made that until Rust releases 2.x, we
just update
to the latest version. If you haven't please read:
https://internals.rust-lang.org/t/cargo-cve-2022-46176-fix-for-older-releases/18152/3?u=sundeep-kokkonda
Assuming that some day, Rust-2.x is released, then one would hope that
1.x would be maintained
for a few years on it's own branch but again the semantic versioning
rules would allow them to
release say 1.288, 1.289, ... and at that time, it would likely be more
clear that we should be following the
1.x releases for older branches and 2.x releases for newer branches.
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.
Once I have enough data, I'll present it here and if it makes sense to ask
the TSC, we can do that.
Upstream is not backporting fixes for a CVE such as this or for less
notable bug fixes,
so we'd be giving up those improvements. I suppose we'd only backport
bug fixes should someone encounter the bug or it becomes equally notable.
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!
Sundeep,
Please also try to backporting the fixes to say Cargo/Rust for kirkstone.
This CVE resulted in ~10 patches so it's hopefully one
of the more complicated back ports and will prove to be a good test case.
../Randy
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
--
# Randy MacLeod
# Wind River Linux
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176070):
https://lists.openembedded.org/g/openembedded-core/message/176070
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]]
-=-=-=-=-=-=-=-=-=-=-=-
