-
-
Notifications
You must be signed in to change notification settings - Fork 14.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[22.11] rustc: 1.64.0 -> 1.66.1 #213287
[22.11] rustc: 1.64.0 -> 1.66.1 #213287
Conversation
Looking at the CVE it applies when cloning with cargo via SSH. We do not do this for our Nix builds and hence for that use case it is not relevant. Upgrading rustc often causes regressions. Of course where the CVE does matter is for users using cargo outside of our Nixpkgs builds and outside of Nix builds. I do not think this is the correct solution, and instead think the correct solution is to simply inform users that 1.64.0 should not be used doing ... because ... instead of forcing an update which can cause regressions both in Nixpkgs and outside. |
These changes look good to me! I don't have an opinion on whether backporting is appropriate or not (depends on our position on security issues). |
@FRidh I talked to @winterqt about this, and both of us think that the fix should be backported if we can make sure that no regressions happen within nixpkgs, since people do use cargo outside and might be affected by the CVE. Another possibility I thought about was defaulting Do you have any suggestions how we might fix the vulnerability other than this and applying the patches? Or can you think of an easier way to apply the patches other than the method mentioned in #210139 (comment)? Perhaps it's better to apply the patches instead to avoid the potential regressions, even if the solution is ugly? |
Fails to link on aarch64-linux. I think we encountered that on unstable as well. Works after pulling #209113 on top.
|
On x86_64-linux
|
https://github.com/rust-lang/rust/releases/tag/1.65.0 (cherry picked from commit eea038c)
(cherry picked from commit a30aa05)
(cherry picked from commit 248d82d)
(cherry picked from commit 671172a)
(cherry picked from commit abbfe51)
(cherry picked from commit f6c0dcf)
(cherry picked from commit 1ffbdda)
(cherry picked from commit 59aec36)
(cherry picked from commit 108f65b)
This change switches to using GCC 11 by default on aarch64-linux, as well as passing `-lgcc` to the linker, per NixOS#201485. See NixOS#201254 and NixOS#208412 for wider context on the issue. (cherry picked from commit 8442601)
https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1661-2023-01-10 Fixes CVE-2022-46176. (cherry picked from commit 21dbce8)
dd6f356
to
57efa85
Compare
aarch64-linux
x86_64-linux
|
All three versions are the same in this respect. It's the issue with old libgcc_s propagated via our glibc package; e.g. NixOS#209113 (cherry picked from commit 77a214e)
It's the issue with old libgcc_s propagated via our glibc package; e.g. NixOS#209113 (cherry picked from commit cdf0283)
This is required to workaround NixOS#201254 (cherry picked from commit ba3db3e)
See NixOS#209113 for context. This has to be done manually because rpm-ostree doesn't use the Cargo setup hooks (which automatically set this flag).
@mweinelt Should be good to go now, thank you for compiling that list/testing. |
(Oh, and for posterity, I didn't cherrypick the rpm-ostree change because that was done alongside a version bump, and it felt weird cherrypicking only a part of a commit. If any part of that commit isn't ideal, including that fact, let me know.) |
Maybe it is easier to break the ssh clone feature entirely and have a message there that users should use a newer rustc version if they want that version? Again, it really is only in a specific feature which is only applicable outside of Nix builds. Or, from CVE:
I don't think there is a right config file we can use, but we can wrap these older cargo versions with
Of course this also suddenly changes behavior again. |
Well, upgrading (default) rustc also changes behavior, as you can see e.g. from all the patches needed across nixpkgs. |
Yep, neither solutions are great. But, speaking as an end-user myself, I much rather be aware of the issue and have a choice, than be forced to potentially integrate a change in Rust version. We've had similar situations before, and it is problematic because it essentially means you cannot just upgrade your stable systems. |
So, no conclusion for now? I'm just asking because 22.11 rebuilds are likely to start soon. |
This is obviously not going to happen. And at this point I'm just sorry about the time wasted. |
Description of changes
https://github.com/rust-lang/rust/releases/tag/1.65.0
https://github.com/rust-lang/rust/releases/tag/1.66.0
https://github.com/rust-lang/rust/releases/tag/1.66.1
Fixes CVE-2022-46176.
This is the path of least resistence, sadly; see the discussion in #210139.
Things done
nix-build -A fd -A synth -A sqlx-cli -A zee -A httplz
sandbox = true
set innix.conf
? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)nixos/doc/manual/md-to-db.sh
to update generated release notes