This security flaw affects not only projects using async-tar but also tokio-tar, an extremely popular fork with over 7 million downloads on crates.io that has also been abandoned.

In reply to @hexa:lossy.network
that's a very exciting idea for a "sidequest"

I'm confused. And a Rust (ecosystem) beginner. Is there a way to run cargo udeps on NixOS on a project that uses the stable toolchain? And should I use rustup or not use rustup?

I've been developing with a direnv+flake that does pkgs.rustPlatform.buildRustPackage and for devShells takes inputsFrom that derivation. And setting RUST_SRC_PATH and removing any $HOME/.cargo/bin entries from PATH in my shellHook—not sure if the latter is right or not, and I also don't 100% remember why I've done it, but I would assume any dynamically linked binaries there to rot when the store gets GCd.

For cargo udeps, I'm told I should use cargo +nightly udeps, which tells me to use rustup, so I try rustup run nightly cargo udeps. I suspect that fails because it invokes rustc, expecting it to be the nightly toolchain rustc, or something? It outputs several error: the option Z is only accepted on the nightly compiler.

I noticed there's also a cargo-udeps packaged in nixpkgs (how if it requires nightly??), but nix-shell -p cargo-udeps --command "cargo udeps" outputs the same errors.

I'm confused. And a Rust (ecosystem) beginner. Is there a way to run cargo udeps on NixOS on a project that uses the stable toolchain? And should I use rustup or not use rustup?

I've been developing with a direnv+flake that does pkgs.rustPlatform.buildRustPackage and for devShells takes inputsFrom that derivation. And setting RUST_SRC_PATH and removing any $HOME/.cargo/bin entries from PATH in my shellHook—not sure if the latter is right or not, and I also don't 100% remember why I've done it, but I would assume any dynamically linked binaries there to rot when the store gets GCd.

For cargo udeps, I'm told I should use cargo +nightly udeps, which tells me to use rustup, so I try rustup run nightly cargo udeps. I suspect that fails because it invokes rustc, expecting it to be the nightly toolchain rustc, or something? It outputs several error: the option \Z` is only accepted on the nightly compiler`.

I noticed there's also a cargo-udeps packaged in nixpkgs (how if it requires nightly??), but nix-shell -p cargo-udeps --command "cargo udeps" outputs the same errors.

I'm confused. And a Rust (ecosystem) beginner. Is there a way to run cargo udeps on NixOS on a project that uses the stable toolchain? And should I use rustup or not use rustup?

I've been developing with a direnv+flake that does pkgs.rustPlatform.buildRustPackage and for devShells takes inputsFrom that derivation. And setting RUST_SRC_PATH and removing any $HOME/.cargo/bin entries from PATH in my shellHook—not sure if the latter is right or not, and I also don't 100% remember why I've done it, but I would assume any dynamically linked binaries there to rot when the store gets GCd.

For cargo udeps, I'm told I should use cargo +nightly udeps, which tells me to use rustup, so I try rustup run nightly cargo udeps. I suspect that fails because it invokes rustc, expecting it to be the nightly toolchain rustc, or something? It outputs several error: the option `Z` is only accepted on the nightly compiler.

I noticed there's also a cargo-udeps packaged in nixpkgs (how if it requires nightly??), but nix-shell -p cargo-udeps --command "cargo udeps" outputs the same errors.

Is there a way to run cargo udeps on NixOS on a project that uses the stable toolchain?

No idea, not familiar with udeps

And should I use rustup or not use rustup?

I would recommend against it and instead recommend either fenix or rust-overlay

I've been developing with a direnv+flake that does pkgs.rustPlatform.buildRustPackage and for devShells takes inputsFrom that derivation. And setting RUST_SRC_PATH

This all sounds fine

and removing any $HOME/.cargo/bin entries from PATH in my shellHook—not sure if the latter is right or not, and I also don't 100% remember why I've done it, but I would assume any dynamically linked binaries there to rot when the store gets GCd.

Yeah you'll hit issues compiling/running stuff that gets installed there. Instead of doing shellHook crimes you should simply never have anything in this directory in the first place. For example, never use cargo install, always package it with nix (if no existing package is available) and install it that way

For cargo udeps, I'm told I should use cargo +nightly udeps, which tells me to use rustup

Yeah, the +toolchain syntax is a rustup thing, only works on rustup shim binaries for cargo and such, not the actual regular binaries. You can use fenix or rust-overlay to get a nightly toolchain, if you want to use stable most of the time you could have two devshells, one for stable and one for nightly

I noticed there's also a cargo-udeps packaged in nixpkgs (how if it requires nightly??)

It probably doesn't require nightly to build, just to run, but that's a guess. Also I think there are some things in nixpkgs that do actually need nightly to build, so that's not too crazy

but nix-shell -p cargo-udeps --command "cargo udeps" outputs the same errors.

Likely because it uses the toolchain from your ambient environment (which in this case is a stable toolchain) rather than e.g. being wrapped to force a particular toolchain (which would be awful UX-wise, so that's why it's not done that way)

cargo-nextest is broken on aarch64-darwin:

error: custom attribute panicked
  --> nextest-runner/src/usdt.rs:63:1
   |
63 | #[usdt::provider(provider = "nextest")]
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = help: message: called `Result::unwrap()` on an `Err` value: IO(Os { code: 2, kind: NotFound, message: "No such file or directory" })

error[E0433]: failed to resolve: could not find `usdt_probes` in `usdt`
   --> nextest-runner/src/usdt.rs:205:23
    |
205 |           $crate::usdt::usdt_probes::run__done!(|| {
    |                         ^^^^^^^^^^^ could not find `usdt_probes` in `usdt`
    |
   ::: nextest-runner/src/runner/imp.rs:381:9
    |
381 | /         crate::fire_usdt!(UsdtRunDone {
382 | |             run_id: self.run_id,
383 | |             profile_name: self.profile.name().to_owned(),
384 | |             total_tests: run_stats.initial_run_count,
...   |
389 | |             paused_nanos: _stopwatch_end.paused.as_nanos() as u64,
390 | |         });
    | |__________- in this macro invocation
    |
    = note: this error originates in the macro `crate::fire_usdt` (in Nightly builds, run with -Z macro-backtrace for more info)

In reply to @quadradical:federated.nexus
i reccomens using crane combined with fenix, i found it great myself. perhaps fenix alone is enough for you though.