Switch to new vsss-rs 5.x stable version

[cr-tk]

Summary & Motivation (Problem vs. Solution)

vsss-rs is an important cryptography library for us.

Based on the Michael Lodder's feedback, he's primarily planning to maintain the latest major version, which is now 5.x. This is a motivation for us to move over to it from the current 4.x pinning.

Switch to vsss-rs 5.1, which is the newest currently available stable version.

The new major version also has a new zeroize target, which we want to use for security hardening.

How I Tested These Changes

This change is not extensively tested yet.

Local cargo test and some fuzz testing via qos_crypto did not uncover issues.

Pre merge check list

• Update CHANGELOG.MD

[cr-tk]

The stagex-build / build artifacts (pull_request) step seems to fail on env -C /src/init cargo build --locked --no-default-features --release --target x86_64-unknown-linux-musl.

Based on some initial debugging, this is actually not a new problem introduced by the dependency changes, but an existing problem introduced in 9082021 which affects the current main ae94332 unrelated to this PR.

cargo build --locked --release builds, but cargo build --locked --no-default-features --release does not. I think this is due to us making use of qos_net::cli::CLI in qos_net regardless of settings, but then marking qos_net::cli as dependent on the proxy cargo target:

   Compiling qos_host v0.1.0 (qos/src/qos_host)
error[E0432]: unresolved import `qos_net::cli`
 --> qos_net/src/main.rs:1:14
  |
1 | use qos_net::cli::CLI;
  |              ^^^ could not find `cli` in `qos_net`
  |
note: found an item that was configured out
 --> qos/src/qos_net/src/lib.rs:9:9
  |
9 | pub mod cli;
  |         ^^^
note: the item is gated behind the `proxy` feature
 --> qos/src/qos_net/src/lib.rs:8:7
  |
8 | #[cfg(feature = "proxy")]
  |       ^^^^^^^^^^^^^^^^^

I think this bug is normally hidden by the fact that the qos_net default target includes proxy. Building with --no-default-features overrides this behavior, triggering the problem.

@r-n-o Can you take a look at this and confirm the above? I'm not sure why the test didn't fail back when we introduced #449 , but perhaps the stagex container behavior/action was different back then.

[r-n-o]

@cr-tk I checked out your branch and ran cargo build --locked --no-default-features --release; also getting the same error locally.

I have no idea why this didn't surface earlier. Your assessment is correct, when default features are disabled, main.rs can't be built because it requires the proxy feature. I think the safest thing to do is to define a main function when the feature is disabled, but because qos_net's CLI is the thing which starts the proxy, it doesn't make sense for it to do anything useful hence a potential patch that looks like this:

iff --git a/src/qos_net/src/main.rs b/src/qos_net/src/main.rs
index 76ebae57..c4398422 100644
--- a/src/qos_net/src/main.rs
+++ b/src/qos_net/src/main.rs
@@ -1,5 +1,14 @@
+#[cfg(feature = "proxy")]
 use qos_net::cli::CLI;
 
+#[cfg(feature = "proxy")]
 pub fn main() {
        CLI::execute();
 }
+
+
+#[cfg(not(feature = "proxy"))]
+pub fn main() {
+       panic!("Cannot run qos_net CLI without proxy feature enabled")
+}

[cr-tk]

@r-n-o thanks for looking into this!
I think your proposed patch is good.
Creating an always panic'ing CLI isn't ideal, but I don't think there's an easy way to make cargo ignore the main.rs file completely in some target configurations. This is probably the most explicit way to handle it, and make it clear that the CLI isn't functioning.

Should we bring in this patch via a separate PR to fast-track, or include it here? I have a slight preference for a separate simple PR, and can create it based on your patch 🙂

[r-n-o]

Should we bring in this patch via a separate PR to fast-track, or include it here? I have a slight preference for a separate simple PR, and can create it based on your patch 🙂

Separate PR sounds good! Here it is: #504

[r-n-o]

@cr-tk the fix has been merged, you should be able to rebase your PR and get a clean build now!

[cr-tk]

@r-n-o thanks, I pushed the rebased version. Looks good locally - I think this is ready for review if the CI tests succeed.

[cr-tk]

We identified the second CI problem. src/init/Cargo.lock also needs updates, but is excluded from the normal Rust workspace, which obscured the issue.

Let's see if this change resolves it.

[cr-tk]

The CI issues are now resolved.
I've completed the Rust dependency security review, see internal documentation.

@r-n-o this PR is ready for review by a second person.

[r-n-o]

Had a look at both lock files and looked at them myself. I relied on the internal analysis if a crate was already listed there. Basically my review is a check which ensures all crates listed in lock files are accounted for.

My guess is that the analysis was run against the workspace's Cargo.lock file (src/Cargo.lock) and didn't account for changes in src/init/Cargo.lock? Luckily there's a lot of overlap so most new crates were already covered, and what I looked at manually was all safe-looking and without surprises.

[r-n-o]

Didn't see it reviewed in the internal analysis. Reviewed it (it's short: https://github.com/Storyyeller/stable_deref_trait/tree/master) and it looks safe to include indeed.

[r-n-o]

It's interesting that there is a new dependency for "spin" but we didn't update this package at all.

[r-n-o]

I don't see this in the analysis either, but looks safe / minimal: https://github.com/bluss/scopeguard/blob/master/src/lib.rs

[r-n-o]

for the sake of completeness: don't see this in the analysis either, but it's in the same family as num-rational or num-complex, both of which are in.

Repo: https://github.com/rust-num/num-iter

[r-n-o]

Likewise for num-integer. Not explicitly in the analysis but looks good to me: https://github.com/rust-num/num-integer (all of these num-* libs are under rust-num)

[r-n-o]

likewise here. Looks good, just another RustNum project lib.

[r-n-o]

Don't see this in the analysis so I looked: Link: https://github.com/Amanieu/parking_lot/tree/master/lock_api -- looks good to me.

[r-n-o]

Also not included. Had a quick look: big files but look okay: https://github.com/BurntSushi/byteorder/blob/master/src/lib.rs, https://github.com/BurntSushi/byteorder/blob/master/src/io.rs

[cr-tk]

Had a look at both lock files and looked at them myself. I relied on the internal analysis if a crate was already listed there. Basically my review is a check which ensures all crates listed in lock files are accounted for.

My guess is that the analysis was run against the workspace's Cargo.lock file (src/Cargo.lock) and didn't account for changes in src/init/Cargo.lock? Luckily there's a lot of overlap so most new crates were already covered, and what I looked at manually was all safe-looking and without surprises.

@r-n-o and I investigated this further, and this turned out to be a non-issue. While the crate versions in question are new to the src/init/Cargo.lock from the perspective of this PR, they have already been present and trusted in the src/Cargo.lock before this PR. They are therefore not newly added Rust dependencies from the perspective of the whole QOS repository and didn't require a new security review. Looking into them didn't hurt, though, thanks @r-n-o !