Fixes all six HIGH findings from the buzz security report, one commit
per finding. Independently reviewed to approval by Max at `0158ae542`,
plus a deep isolated live pass (clean-room compose stack, weird ports,
full product matrix) at the same head — see the buzz-security thread for
evidence. `fe65c07c3` merges current `origin/main` on top (new commit,
no rebase), inheriting the nostr 0.44.6 bump (#3135) and relay-admin ban
gate (#3128).
## Findings and fixes
| Finding | Commit | Fix |
|---|---|---|
| 003 — quinn-proto RUSTSEC-2026-0185 | `e5dcdec72` | Bump quinn-proto
0.11.14 → 0.11.16 (lockfile-only) |
| 002/004 — linkify-it quadratic-parse DoS (GHSA-22p9-wv53-3rq4,
GHSA-v245-v573-v5vm) | `923b3c20f` | pnpm override `linkify-it: ^5.0.2`;
`pnpm why` confirms a single 5.0.2 copy |
| 001 — media reads served unauthenticated by default | `0f277e3e2` |
Helm `requireMediaGetAuth` defaults to `true` + rendered-chart test
pinning the default |
| 006 — removed workflow owners retain webhook-exfiltration authority |
`4749bd56c` | Fail-closed per-fire authority gate (current owner/admin
membership) on **all four** trigger doors (on_event, scheduler
pre-claim, manual trigger, webhook — masked as generic 404), save-time
gate for `call_webhook` defs, durable disable-on-removal wired to kinds
9001 + 9022 |
| 005 — git Smart-HTTP reads ignore channel membership | `e648f2dba` +
`0158ae542` | `authorize_git_read`: caller's **current active
membership** in the repo's bound channel, checked before any
hydration/subprocess on all three read doors (`info_refs` for both
services + `upload_pack` POST). Uniform generic 404 denials (no
membership probing), no repo-owner bypass, first-`buzz-channel`-tag
binding semantics fail closed on ambiguous duplicates (mutation-verified
test). Resolution follows the live kind:30617 announcement, so
deleted/replaced announcements deny immediately. The committed
`e2e-git-perms.sh` guest scenario previously asserted the vulnerability
— now asserts denial. |
## Behavior changes to be aware of
1. **Unbound repos fail closed for git reads.** `buzz repos create`
emits no `buzz-channel` tag, so CLI-created repos without a binding are
unreadable via git HTTP. Correct per finding 005's fail-closed posture;
a follow-up could bind CLI-created repos at creation time.
2. **006 is conservative:** a workflow disabled on owner removal does
not auto-re-enable if the owner is re-added — explicit re-enable
required.
3. Merge conflict resolution in `fe65c07c3`: kept main's
`@radix-ui/react-dismissable-layer` 1.1.19 bump alongside the linkify-it
security override (`pnpm-workspace.yaml` + lockfile).
## Verification at the merge head `fe65c07c3` (same shell)
- buzz-relay `--lib`: 761 passed / 1 failed — the lone red is the known
pre-existing `mesh_demo::demo_join_forwarded_arm_round_trips_echo` 504
flake, present on main
- SEC-005 module incl. PG behavioral matrix: 8/8 (removed-member,
never-member, owner-no-bypass, deleted-30617, malformed/ambiguous
binding, owner-mismatch all denied)
- buzz-workflow 153/0, buzz-db 84/0; `clippy --all-targets -D warnings`
+ `fmt --check` clean
- Desktop JS 3637/3637, tsc clean, biome clean,
file-size/px-text/pubkey-truncation gates clean
- `helm lint` + `helm unittest` (40/40) on `deploy/charts/buzz`
- All five pre-push hooks green (desktop-check, desktop-test,
rust-tests, desktop-tauri-test, branch-skew)
Prior review evidence at `0158ae542` (pre-merge): Max's independent
exact-head approval + clean-room live regression pass
(`WORK_LOGS/2026-07-27_SECURITY_HIGH_LIVE_TEST.md` in his workspace).
Max will re-run the deep local pass at this post-merge head before
merge.
---------
Signed-off-by: Tyler Longwell <tlongwell@block.xyz>
Signed-off-by: npub1qyvc0c5kl4gqv2fd97fsk46tu378sqgy35vc83rvgfwne90sel7s0ed67d <011987e296fd5006292d2f930b574be47c7801048d1983c46c425d3c95f0cffd@buzz.block.builderlab.xyz>
Co-authored-by: npub1qyvc0c5kl4gqv2fd97fsk46tu378sqgy35vc83rvgfwne90sel7s0ed67d <011987e296fd5006292d2f930b574be47c7801048d1983c46c425d3c95f0cffd@buzz.block.builderlab.xyz>
Co-authored-by: Tyler Longwell <tlongwell@block.xyz>
## 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>
Signed-off-by: Tyler Longwell <tlongwell@block.xyz>
Co-authored-by: npub1jmc9dt2lyvzu3h0kxlwxt5zg4fxp9476awyxw6gwxn72g6cw7exqs64whm <96f056ad5f2305c8ddf637dc65d048aa4c12d7daeb8867690e34fca46b0ef64c@buzz.block.builderlab.xyz>
Co-authored-by: Tyler Longwell <tlongwell@block.xyz>
