Desktop: just desktop-release-build packages empty sidecar placeholders

[zime78]

Important

Do not include security vulnerabilities in a public issue. Report them
privately through a GitHub security advisory.

Describe the bug

just desktop-release-build is documented as building the full desktop Tauri app locally, but the recipe never builds or copies real sidecar binaries. It touches empty placeholders under desktop/src-tauri/binaries/ and then runs pnpm tauri build. Tauri's externalBin list copies those files into the .app / installer, so a source-built “release” app can ship 0-byte buzz-acp, buzz-agent, buzz-dev-mcp, git-credential-nostr, buzz, and (non-Windows) buzz-backend-kubernetes.

This is separate from the dev stub-shadowing bugs (#4747, #3664, #3927). Those are about just dev / _ensure-sidecar-stubs hiding a real binary on PATH. This one is the local release recipe packaging the stubs themselves.

GitHub Actions release.yml already does the right thing (cargo build --release -p … then ./scripts/bundle-sidecars.sh). Official GitHub-published Desktop builds are not the subject of this report. The gap is the in-tree Just recipe that contributors and self-hosters use to make a local app.

Steps to reproduce

1. Check out origin/main (reproduced against c3132c3ee982d194cd0198ad07b57ec8bd726e4e).
2. Read Justfile desktop-release-build (Justfile:263-277). It only:
   • touch desktop/src-tauri/binaries/buzz-acp-$TARGET (and the other sidecar names)
   • pnpm install
   • pnpm tauri build --features mesh-llm --target …
3. Confirm desktop/src-tauri/tauri.conf.json bundle.externalBin lists those same names (binaries/buzz-acp, binaries/buzz-agent, …).
4. Run just desktop-release-build (macOS example: default aarch64-apple-darwin).
5. Inspect the bundled sidecars next to the app executable, e.g. Buzz.app/Contents/MacOS/buzz-acp (and the other externalBin names).

Expected behavior

A local release build should fail closed unless each sidecar is a real, nonempty, executable binary for the target — the same contract scripts/bundle-sidecars.sh already enforces for CI/canary/release workflows.

Suggested shape (no new packaging invention):

1. cargo build --release --target "$TARGET" for the sidecar crates.
2. ./scripts/bundle-sidecars.sh "$TARGET" instead of touch.
3. After tauri build, reject 0-byte / non-executable sidecars in the output bundle.

Version and platform

• Buzz version: 0.5.20 (desktop/package.json on origin/main c3132c3ee)
• OS: macOS (arm64). Recipe is target-parameterized; Windows would touch .exe stubs the same way via _ensure-sidecar-stubs, but this report is about desktop-release-build.

Logs / additional context

Current recipe on origin/main:

desktop-release-build target="aarch64-apple-darwin":
    TARGET={{target}}
    mkdir -p desktop/src-tauri/binaries
    touch "desktop/src-tauri/binaries/buzz-acp-$TARGET"
    touch "desktop/src-tauri/binaries/buzz-agent-$TARGET"
    # …
    touch "desktop/src-tauri/binaries/buzz-$TARGET"
    pnpm install
    cd {{desktop_dir}} && pnpm tauri build --features mesh-llm --target {{target}}

Contrast with .github/workflows/release.yml (“Build sidecars”):

cargo build --release -p buzz-acp -p buzz-agent -p buzz-backend-kubernetes -p buzz-dev-mcp -p git-credential-nostr -p buzz-cli
./scripts/bundle-sidecars.sh

scripts/bundle-sidecars.sh already errors if a release binary is missing from target/…/release. The Just recipe never calls it.

Related, not duplicates:

• Desktop dev builds: empty sidecar stubs shadow real binaries, so agent sign-in fails as "Sign-in unavailable" #4747 Desktop dev builds: empty sidecar stubs shadow real binaries → “Sign-in unavailable”
• dev lane: managed agents resolve a zero-byte buzz sidecar — just dev never replaces the Tauri stubs beside the app executable #3664 / bug(dev): just dev leaves non-executable sidecar stubs, breaking ACP authentication #3927 same stub-shadowing class for just dev

Happy to follow with a small PR that wires desktop-release-build to the existing bundle script and adds a fail-closed check.