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.

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.

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.