Upstream has issued an advisory today (November 1): https://www.openwall.com/lists/oss-security/2021/11/01/1 The issue is fixed upstream in 1.56.1. Mageia 8 is also affected.
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=29615Status comment: (none) => Fixed upstream in 1.56.1Whiteboard: (none) => MGA8TOO
Status: NEW => ASSIGNED
rust-1.56.1-1.mga9 is building now for Cauldron. Started working on the update from rust 1.51.1 in Mageia 8 to 1.56.1, I'll add the advisory once it's ready to test.
Version: Cauldron => 8Whiteboard: MGA8TOO => (none)
The Mageia 8 update candidate is now available. Advisory: ========= Updated rust packages fix security vulnerability This update mitigates a security concern in the Unicode standard, affecting source code containing "bidirectional override" Unicode codepoints: in some cases the use of those codepoints could lead to the reviewed code being different than the compiled code (CVE-2021-42574). rustc mitigates the issue by issuing two new deny-by-default lints detecting the affected codepoints in string literals and in comments. The lints will prevent source code files containing those codepoints from being compiled, protecting developers and users from the attack. This update also provides new features and bugfixes included in Rust since the previously packaged version 1.51.1. See the referenced release notes for details. References: - https://www.openwall.com/lists/oss-security/2021/11/01/1 - https://blog.rust-lang.org/2021/05/06/Rust-1.52.0.html - https://blog.rust-lang.org/2021/06/17/Rust-1.53.0.html - https://blog.rust-lang.org/2021/07/29/Rust-1.54.0.html - https://blog.rust-lang.org/2021/09/09/Rust-1.55.0.html - https://blog.rust-lang.org/2021/10/21/Rust-1.56.0.html - https://blog.rust-lang.org/2021/11/01/Rust-1.56.1.html SRPMs in core/updates_testing: ============================== rust-1.56.1-1.mga8 RPMs in core/updates_testing: ============================= cargo-1.56.1-1.mga8.x86_64.rpm cargo-doc-1.56.1-1.mga8.noarch.rpm clippy-1.56.1-1.mga8.x86_64.rpm rls-1.56.1-1.mga8.x86_64.rpm rust-1.56.1-1.mga8.x86_64.rpm rust-analysis-1.56.1-1.mga8.x86_64.rpm rust-debugger-common-1.56.1-1.mga8.noarch.rpm rust-doc-1.56.1-1.mga8.x86_64.rpm rust-gdb-1.56.1-1.mga8.noarch.rpm rust-lldb-1.56.1-1.mga8.noarch.rpm rust-src-1.56.1-1.mga8.noarch.rpm rust-std-static-1.56.1-1.mga8.x86_64.rpm rustfmt-1.56.1-1.mga8.x86_64.rpm
Assignee: rverschelde => qa-bugs
It looks like this broke building Firefox on aarch64: http://pkgsubmit.mageia.org/uploads/failure/8/core/updates_testing/20211102182157.luigiwalser.duvel.3273525/log/firefox-91.3.0-1.mga8/build.aarch64.0.20211102183032.log
CC: (none) => rverscheldeKeywords: (none) => feedbackStatus comment: Fixed upstream in 1.56.1 => (none)
Good call testing a Firefox build. Looks like Fedora ran into the same issue: https://bugzilla.redhat.com/show_bug.cgi?id=2019160 And they opted for disabling the aarch64 build for Firefox: https://src.fedoraproject.org/rpms/firefox/c/ff8d52acc2e7500b406de3393531ee2627c93108?branch=rawhide That's only on Fedora 33 for them, so I guess it might be an incompatibility with the llvm version (they have llvm 11.0 on F33, like we do on Mageia 8). We could try building rust against the vendored llvm 13.0 for aarch64 to see if that fixes it.
If there's something you can try that might fix it, take a swing. I don't personally care about ARM, but since aarch64 is supposed to be officially supported and we've already shipped Firefox there, we should continue to update it if we can.
Mageia8, x64 Decided not to look for PoC because that seems like a packager/developer task. QA should perhaps only follow the PoC trail if specifically requested. Installed all the packages and then updated them via qarepo. Followed previous tests of rust: $ cd qa/rust $ cd rust-hello_world $ cargo run Compiling hello_world v0.0.1 (/home/lcl/qa/rust/rust-hello_world) Finished dev [unoptimized + debuginfo] target(s) in 2.75s Running `target/debug/hello_world` Hello World! I'm a Rustacean! $ rustfmt -v src/main.rs Formatting /home/lcl/qa/rust/rust-hello_world/src/main.rs Spent 0.004 secs in the parsing phase, and 0.000 secs in the formatting phase $ cd .. $ ls list report.23701 RustProgrammingLanguage.pdf manifest report.29033 RustProgrammingLanguage-versions/ manifest-1.56 rsvg/ rusty report.23328 rust-hello_world/ `rg -help` delivers a long summary of the rust ripgrep command. $ rg -s cargo . ./report.23328 6:$ cargo install ripgrep --force 16: Replacing /home/lcl/.cargo/bin/rg 18:$ ls .cargo 20:$ ls .cargo/bin 28:$ rg cargo 30:3457:cargo (0.0.1) 31:3458:cargowise (0.8.4) ........... That works very well. $ rg --version ripgrep 11.0.2 -SIMD -AVX (compiled) +SIMD +AVX (runtime) Went back to the user directory and installed ripgrep. $ cargo install ripgrep --force Updating crates.io index Downloaded ripgrep v13.0.0 Downloaded 1 crate (272.1 KB) in 0.43s Installing ripgrep v13.0.0 Downloaded thread_local v1.1.3 ........... Downloaded encoding_rs v0.8.29 Downloaded 42 crates (4.5 MB) in 0.73s (largest was `encoding_rs` at 1.4 MB) Compiling memchr v2.4.1 Compiling cfg-if v1.0.0 Compiling proc-macro2 v1.0.32 Compiling log v0.4.14 .......... Compiling ripgrep v13.0.0 Compiling grep-printer v0.1.6 Compiling grep v0.2.8 Finished release [optimized + debuginfo] target(s) in 1m 12s Replacing /home/lcl/.cargo/bin/rg Replaced package `ripgrep v11.0.2` with `ripgrep v13.0.0` (executable `rg`) $ urpmq --whatrequires rust | sort -u cargo clippy rls rust rust-packaging clippy is part of the update. $ rpm -q clippy clippy-1.56.1-1.mga8 Described on GitHub as "A bunch of lints". lints are mentioned in the advisory in comment 2. Not much more we can do here so ready to give this an OK for 64-bits. Regarding comments 3, 4, 5 should we with-hold or send it on?
CC: (none) => tarazed25
Hold it until we figure out what we're doing about Firefox.
(In reply to Rémi Verschelde from comment #4) > Looks like Fedora ran into the same issue: > https://bugzilla.redhat.com/show_bug.cgi?id=2019160 > > That's only on Fedora 33 for them, so I guess it might be an incompatibility > with the llvm version (they have llvm 11.0 on F33, like we do on Mageia 8). > > We could try building rust against the vendored llvm 13.0 for aarch64 to see > if that fixes it. So for the record, I confirmed with the Fedora Rust maintainer that it's indeed due to Firefox using unstable aarch64 SIMD intrinsics which depend on LLVM 12+. Rebuilding Rust against the bundled LLVM 13.0 for aarch64 only didn't work, as the build node ran out of memory when linking. Could be made to work with some effort but I think it's not worth it. Instead, I rebuilt Firefox with the `neon` feature disabled for aarch64, which worked fine: http://svnweb.mageia.org/packages/updates/8/firefox/current/SOURCES/qcms-disable-neon-aarch64.patch?view=markup&pathrev=1753852 It's only used for this `gfx/qcms` crate and the code is written so that it's optional, so I think it's not a big deal to have it disabled. So this update candidate can continue being tested, no change to the Rust packages. The Firefox update will be tracked in a separate bug report, it's the regular ESR update.
Keywords: feedback => (none)
Ok thanks. Please note that you shouldn't have added a subrel to firefox, which I fixed in SVN, but then you submitted from an old revision. Always specify the package name when running the submit command.
(In reply to David Walser from comment #9) > Ok thanks. Please note that you shouldn't have added a subrel to firefox, > which I fixed in SVN, but then you submitted from an old revision. Always > specify the package name when running the submit command. I added a subrel because the buildsystem wouldn't let me submit without one, due to the previous failed build still lingering in the upload queue. That's a long time issue with our buildsystem and the workaround is to bump rel, or ask a sysadmin to cleanup.
Ahh yes, I hate that bug.
Fedora has issued an advisory for this today (November 5): https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/LQNTFF24ROHLVPLUOEISBN3F7QM27L4U/
thunderbird and firefox builds still work, so I consider the packages tested enough...
Whiteboard: (none) => MGA8-64-OK, MGA8-32-OKKeywords: (none) => advisory, validated_updateCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2021-0517.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED