fix(deps): bump nostr to 0.44.6 for RUSTSEC-2026-0216 (NIP-44 remote DoS)

[tlongwell-block]

Summary

cargo-deny started failing on every PR and on main when RUSTSEC-2026-0216 was published mid-afternoon today. Nothing in the tree changed — cargo-deny fetches the advisory DB at run time, so main's own Security job passed at 00ecf2c and then began failing on the same commit.

error[vulnerability]: Remote Denial of Service via malformed NIP-44 v2 payload
  Cargo.lock:432  nostr 0.44.3  —  RUSTSEC-2026-0216
advisories FAILED, bans ok, licenses ok, sources ok

The nostr NIP-44 v2 decrypt path reads a 2-byte unpadded-length prefix via buffer[0..2] after the HMAC check passes, without verifying the decrypted buffer holds 2 bytes. A sender who holds the conversation key — i.e. any DM sender — can craft a payload that decrypts to 0 or 1 bytes and panic the receiver. Remote DoS through any relay that delivers the event. No key material, plaintext, or memory corruption.

Affects 0.26.0 through 0.44.4. Fixed in 0.44.5.

The change

Lockfiles only, 6 insertions / 6 deletions. The manifest already declares nostr = "0.44" — a caret range — so 0.44.6 needs no Cargo.toml edit.

Lockfile	Before	After
Cargo.lock	0.44.3	0.44.6
desktop/src-tauri/Cargo.lock	0.44.4	0.44.6

The desktop lockfile is the part worth reviewing. desktop/src-tauri is excluded from the root workspace (Cargo.toml:31), and the Security job runs cargo-deny check at the repo root — so it never sees that lockfile. It was pinning a vulnerable and yanked 0.44.4 that no CI check would ever have flagged. Desktop calls nip44::decrypt at commands/identity.rs:495. Credit to @eva for catching this; I'd have shipped the root-only fix and left it sitting there.

This isn't optional maintenance. 0.44.0 through 0.44.4 are all yanked on crates.io. 0.44.5 and 0.44.6 are the only live versions in our range — staying put isn't an available option.

On the two extra lines in the desktop lockfile

The desktop bump also repoints two existing dependency edges:

nostr-derive: syn 2.0.118 -> syn 1.0.109
tempfile:     getrandom 0.4.3 -> getrandom 0.3.4

I checked these rather than waving them through: no packages are added or removed — both versions were already present in the graph, so only which edge points where changed. The resolution is stable across repeated re-resolves, and a plain re-resolve without the bump produces zero diff, so this isn't pre-existing lockfile staleness leaking in.

Verification

At this commit, in a clean worktree off origin/main:

• cargo-deny check advisories → advisories ok, exit 0. The same tree before the bump reported advisories FAILED with this advisory, so the check is doing real work, not passing vacuously.
• ./scripts/run-tests.sh unit → all five packages pass.
• cargo test -p buzz-core 229/229, -p buzz-cli 250/250, -p buzz-relay --lib 750 pass / 1 fail — the sole failure api::mesh_demo::tests::demo_join_forwarded_arm_round_trips_echo is pre-existing and reproduces identically at unmodified 00ecf2c.
• desktop-tauri-test passed in the pre-push hook, which exercises the crate whose lockfile changed.

Why not a deny.toml ignore

Considered and rejected. This is a reachable panic triggerable by any DM sender, and buzz-acp agents decrypt DMs from arbitrary senders. Suppressing it would ship a live remote-DoS to every agent and client in order to make a dashboard green.

Note on spin

The yanked spin 0.9.8 / 0.10.0 warnings in the same job are not what fails CI — the log has exactly one hard error, this one. They're warning[yanked], and warnings don't fail the build. spin is also three levels transitive (mesh-llm-host-runtime → mdns-sd → flume → spin) under a dev-dependency, so it isn't ours to bump. Left alone deliberately.

Follow-up

Unblocks #3128 (relay-admin ban gate), which has a zero dependency-file delta and will inherit this cleanly once main is merged in.

Co-authored-by: Tyler Longwell tlongwell@block.xyz
Signed-off-by: Tyler Longwell tlongwell@block.xyz