rustc: 1.66.0 -> 1.66.1

[winterqt]

Description of changes

https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1661-2023-01-10

Fixes CVE-2022-46176.

Let me know if this should go in staging instead.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux, nix-build -A fd
  • x86_64-darwin
  • aarch64-darwin, nix-build -A fd
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.05 Release Notes (or backporting 22.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[zowoq]

Let me know if this should go in staging instead.

I'd say yes but I'll let @vcunat decide.

[winterqt]

I see arguments for both sides, but I created this on -next so it can be merged ASAP if that's what we want.

[mweinelt]

We can take this into staging-next, it's currently delayed on darwin issues anyhow.

[mweinelt]

Built fd on x86_64-linux. LGTM.

[winterqt]

I'll do the 22.11 backport tomorrow.

[vcunat]

To staging-next-22.11, please. There's much less rebuilds finished in there than on staging-next.

[winterqt]

Poked the Rust security and Cargo teams about this, just to make sure we're doing things correctly on our end.

[winterqt]

@vcunat I assume if I submitted the backport PR in ~20 hours, that it'd have to go into staging-22.11, right?

[winterqt]

@vcunat If I submitted the backport in ~17 hours, I assume it should go in staging-22.11?

[vcunat]

Assuming it will be suitable for (almost) immediate merging, I believe it should be fine for the current staging-next-22.11 iteration.

[winterqt]

@Mic92 @zowoq @alyssais @figsoda @tjni @NickCao (tagging some folks that have done Rust stuff recently.)

Okay, so, backporting this fix to 1.64 is hell due to the added dependencies. My current hack job includes doing this:

  patches = (lib.imap1 (i: { commit, hash, excludes ? [] }: fetchpatch {
    inherit hash excludes;
    name = "CVE-2022-46176-${builtins.toString i}.patch";
    url = "https://github.com/rust-lang/cargo/commit/${commit}.patch";
    stripLen = 1;
    extraPrefix = "src/tools/cargo/";
  }) [
    { commit = "c9bff1ec6d147e0254ecfcafe6325ef1643edb6d"; excludes = [ "*/Cargo.toml" ]; hash = "sha256-rNldAJOYqYpvqoPw7C9TzedpH5qrgtuNac7XIH8DKhE="; }
    { commit = "95c98116e31d99951b128dbe1564264b7a43f52c"; hash = "sha256-bgA6mzTE7/KGSWL3ANkhnwQYzzpmlRSeNw8B4Hl6YaY="; }
    { commit = "c552222a72f6a40b85d829c1298dee19b45ad3f3"; hash = "sha256-TQfCuoiCTgb6m1/iEFDW9PiHjtzUW6S8OLwgVLjAyF8="; }
    { commit = "e8999621bead5aab94412038cb551b1a5475e554"; hash = "sha256-tpmHi9E1h2xlWa8X6mtq3M/34nazV1yfU3gqa3K1FHg="; }
    { commit = "1ad1d3db10b71805ae9ada9f0ee7366d94adce2a"; hash = "sha256-rCPuVFQqURDkxcYNfaEX1qT27BiAppcWwB2yI65q00g="; }
    { commit = "895031c4c1892dc95cd2774a5f8b173142ba5c2c"; hash = "sha256-Qi7wuLXCxrMpCYqxKFnCn1J8/sav5ps9cNiiUeYxII4="; }
    { commit = "cb9eeffdfba8ccff3b018b9b1c72f7dfd7a370f2"; excludes = [ "*/Cargo.toml" ]; hash = "sha256-fSPxH61smQm9OvHbSbefdFBz91xBbm79YDMJCoB8kR4="; }
  ]) ++ [

  ];

  cve-2022-46176-deps = rustPlatform.fetchCargoTarball {
    src = ./CVE-2022-46176-deps;
    name = "CVE-2022-46176-deps";
    CARGO_HTTP_CAINFO = "${buildPackages.cacert}/etc/ssl/certs/ca-bundle.crt";
    SSL_CERT_FILE = "${buildPackages.cacert}/etc/ssl/certs/ca-bundle.crt";
    hash = "sha256-uE2YtPH4pxuUWpnco+byoPaO/bOCgFSr9nP9DLYxLN4=";
  };

  postPatch = ''
    unpackFile ${cve-2022-46176-deps}
    mv CVE-2022-46176-deps-vendor.tar.gz cve-2022-46176-deps
  '';

(This doesn't even hook up the dependencies, that's a whole mess in it of itself because I need to filter the tree and remove a bunch of stuff.)

So, we have two options here for 22.11:

1. Backport it using weird hacks like the above. I'd really love to not do this, because it just adds increased complexity for no good reason.
2. Bump 22.11 to 1.66.1. This will cause (to my knowledge) zero breaking changes. (The only breaking change in between 1.64.0 and 1.66.1 are that RLS was removed, but we dropped RLS in September, and I really don't think anyone is using it at this point.)

I appreciate any and all thoughts, thanks.

[figsoda]

hook up the dependencies

any ideas why cargoPatches wouldn't work

zero breaking changes

I don't think that's true, there has been a handful a breakages fixed by @tjni:
https://github.com/NixOS/nixpkgs/pulls?q=fix+rust+1.65
#207451

but still if we have to do the dependencies wizardry, I would prefer to backport this and the other fixes to 22.11 instead

[winterqt]

hook up the dependencies

any ideas why cargoPatches wouldn't work

Because the rustc source archive already contains dependencies (thus cargoPatches isn't relevant here); we don't want to blindly inject them into their vendor directory -- it'd be better to filter the dependency tree and use patch entries in the Cargo.toml (which is what the 1.66.0 patches do).

zero breaking changes

I don't think that's true, there has been a handful a breakages fixed by @tjni: NixOS/nixpkgs/pulls (fix rust 1.65) #207451

Ah, right. Good catch.

but still if we have to do the dependencies wizardry, I would prefer to backport this and the other fixes to 22.11 instead

Agreed, I just don't think it's worth the complexity. 😕

[vcunat]

zero breaking changes

Certainly not true. I see new failures in staging-next on every rust update.

[winterqt]

zero breaking changes

Certainly not true. I see new failures in staging-next on every rust update.

(Do you happen to recall what these were, other than lint-related changes?)

[vcunat]

I don't recall. I also saw some rust packages regressing in this iteration (merged a while ago), but I didn't even try to isolate that rustc update was the trigger. Examples: https://hydra.nixos.org/build/205119286 https://hydra.nixos.org/build/205185861 https://hydra.nixos.org/build/205174981

[figsoda]

opened #210736 and #210738, both were caused by #207804 so we don't have to backport the changes, might be good to backport the dogdns fix though since it also makes the build reproducible

not sure about fractal though

[winterqt]

@figsoda Beat me to it, thanks. They can go straight to master since -next was merged :)

[figsoda]

ah, that's why there wasn't a giant diff when github defaulted to master

thanks, I have rebased them to master