chore(deps): update dependencies and patch cargo audit advisories

[platinummonkey]

Summary

Refreshes the dependency tree to clear the cargo audit findings and bring five direct dependencies up a major version. cargo audit goes from 3 vulnerabilities + 4 warnings to 2 vulnerabilities + 0 warnings, with the two remaining findings unfixable upstream (see below).

Each bump is a separate commit so any individual one can be dropped without losing the rest. The first commit carries all of the security value and touches no code.

Changes

Security (lockfile only — db10b0e)

• quinn-proto 0.11.14 → 0.11.16 — RUSTSEC-2026-0185, 7.5 high, remote memory exhaustion via unbounded out-of-order stream reassembly
• anyhow 1.0.102 → 1.0.104 — RUSTSEC-2026-0190, unsoundness in Error::downcast_mut() (patched in >= 1.0.103)
• Clears three yanked crates: aes 0.9.0 → 0.9.1, crypto-bigint 0.7.3 → 0.7.5, spin 0.9.8 → 0.9.9

Major bumps (no code change required)

• base64 0.22 → 0.23 (Cargo.toml:112) — URL_SAFE_NO_PAD engine API unchanged
• aes-gcm 0.10 → 0.11 (Cargo.toml:121) — also dedupes against the 0.11 copy already present transitively
• jsonschema 0.46 → 0.49 (Cargo.toml:166) — Retrieve impl and options() builder at src/commands/idp/migrate.rs:1076,1143 unchanged
• yamux 0.13 → 0.14 (Cargo.toml:127) — tunnel multiplexer API unchanged
• tokio-tungstenite 0.29 → 0.30 (Cargo.toml:126) — rustls-tls-native-roots feature and stream API unchanged

russh 0.61 → 0.62 (Cargo.toml:128, src/tunnel.rs) — requires code changes

0.62 reworked the channel-open callback contract: handlers now receive a ChannelOpenHandle and return Result<()> instead of Result<bool>. Accepting requires an explicit reply.accept().await, and dropping the handle sends an automatic AdministrativelyProhibited rejection — so a mechanical signature-only patch would have silently rejected every channel.

• channel_open_session (src/tunnel.rs:242) accepts explicitly instead of returning Ok(true)
• channel_open_direct_tcpip (src/tunnel.rs:251) accepts after the TCP connect succeeds but before spawning the read pump, so no data is written to a channel the client has not yet seen accepted
• A failed TCP connect still propagates as before, and now additionally drops the handle, which rejects the channel instead of leaving the open request unanswered

This bump also pulls the SSH crypto chain off pre-release versions: curve25519-dalek 5.0.0-rc.0 → 5.0.0, ed25519-dalek 3.0.0-rc.0 → 3.0.0, elliptic-curve 0.14.0-rc.33 → 0.14.1, and p256/p384/p521 → 0.14.0.

Deliberately not included

keyring 3 → 4 — deferred. 4.x is a full restructure into a keyring-core facade plus per-store crates. Its own docs state that applications wanting to control which store is used per platform "should not be linking to this library at all." src/auth/storage.rs is exactly that case: it probes Secret Service and falls back to the kernel keyring (keyutils) on Linux (src/auth/storage.rs:728-743). The 4.x v1 compatibility shim hardcodes zbus-secret-service on Linux and exposes neither keyring::keyutils nor set_default_credential_builder, so there is no way to express that fallback through it — shipping the shim would regress headless/CI Linux users. Doing it properly means migrating ~60 keyring::Entry/keyring::Error call sites in code and tests to keyring-core with explicit per-platform store setup. That deserves its own PR, and there is no advisory against keyring 3. Worth noting the current feature list at Cargo.toml:149 is already stale — cargo outdated reports all six requested features as obsolete in 4.x.

rsa RUSTSEC-2023-0071 (Marvin attack, medium) — unfixable. Both copies remain: rsa 0.9.10 via our direct ssh-key 0.6 dep, and rsa 0.10.0-rc.18 via russh. Upstream has published no fixed release. ssh-key has no stable 0.7 (latest is 0.7.0-rc.11), so bumping that dep would mean taking a direct dependency on a release candidate. Left as-is and not suppressed; per discussion, no cargo audit CI gate is being added in this PR.

One partial path does exist and was deliberately not taken: russh gates its rsa copy behind an optional but default-on rsa feature, so default-features = false (plus re-enabling the rest) would drop that finding. Not done here because it removes RSA host-key support from the SSH tunnel — a functional change, not a dependency bump — and src/tunnel.rs has no test coverage to catch the regression. Worth its own PR if we want RSA gone.

wasm-bindgen family — left at their exact =0.2.114 / =0.3.91 pins. Commit c39359a pinned these specifically for WASI compatibility.

reqwest — stays at 0.13.2. cargo update respects the <0.13.3 bound, preserving the wasm32-wasi tokio cfg workaround documented at Cargo.toml:88-90.

Testing

• cargo test --bin pup -- --test-threads=1 — 1599 passed, 0 failed
• cargo clippy --all-targets -- -D warnings — clean
• cargo fmt --check — clean
• cargo check --target wasm32-wasip2 --no-default-features --features wasi — clean
• cargo check --lib --target wasm32-unknown-unknown --no-default-features --features browser — clean
• cargo audit — 3 vulnerabilities + 4 warnings → 2 vulnerabilities + 0 warnings

Two caveats worth reviewer attention:

1. src/tunnel.rs has no test coverage (cargo test tunnel matches 0 tests), so the russh handler migration is verified by compilation and API-contract reading against the vendored russh 0.62.4 source, not by execution. The accept/reject path is the part to exercise manually against a live synthetics tunnel.
2. cargo check --all-features fails on main today, before any change here, with E0428: the name config_dir is defined multiple times (src/config.rs:440 and src/config.rs:457 — native vs wasi/browser). Not introduced by this PR and not addressed in it, but it means --all-features is not a usable smoke test; the three real feature sets were checked individually instead.

---

🤖 Generated with Claude Code