auto-update execs github release binaries with no signature verification (rce on every install)

[rx18-eng]

Body

src/auto_update.rs downloads a binary from github releases and execs it with no checksum, no signature, no gpg. anyone who compromises a single dmnd-pool maintainer's github account can ship a backdoored release and get code execution on every running dmnd-client globally on the next restart.

the chain in code (src/auto_update.rs:60-106)

download.download_to(&mut file).expect(...);            // no verification
std::fs::rename(&new_exe, &original_path)               // swap binary
std::fs::set_permissions(&original_path, 0o755)         // chmod +x
std::process::Command::new(&original_path).exec();      // run it

default-on

• Cargo.toml:39: self_update = {version = "0.42.0", features = ["archive-tar"]} - the crate's signatures feature exists for ed25519ph verification, just not enabled
• auto_update.rs never calls .verifying_keys(...) - defaults to empty
• src/config.rs:471: auto_update.unwrap_or(true) - on by default
• runs every startup before serving miners (src/lib.rs:130-134)

repro

TOKEN=demo cargo run 2>&1 | grep -E "auto_update|Updated|version"

output:

unverified binary swap and exec, no human in the loop.

why it matters

post-exec, attacker code runs as the dmnd-client user - has the TOKEN, can redirect hashrate, can persist on host. bitcoin-core / electrum / sparrow / lnd / clightning all verify release signatures. mining proxy in the share-submission path is the same risk class.

fix

enable the feature + use a pinned pubkey:

self_update = { version = "0.42.0", features = ["archive-tar", "signatures"] }

const RELEASE_PUB_KEY: [u8; 32] = [/* ... */];

.verifying_keys(vec![RELEASE_PUB_KEY])

sign release artifacts with zipsign in ci. or as an immediate interim, flip the default to false so the global blast radius drops while signing infra gets set up.

[rx18-eng]

@Fi3 @Priceless-P @jbesraa let me know if this seems valid to you !