-
v1.25.7
StableAll checks were successfulCI / Rust clippy (push) Successful in 1m52sCI / Rust fmt (push) Successful in 1m17sCI / Rust test (push) Successful in 6m2sCI / UI (SvelteKit) (push) Successful in 1m20sCI / Security Audit (push) Successful in 1m23sdocs / build (push) Successful in 36sRelease / Docker Multi-Arch (push) Successful in 22m50sRelease / Binary aarch64-unknown-linux-gnu (push) Successful in 12m15sRelease / Binary x86_64-unknown-linux-gnu (push) Successful in 11m6sRelease / Linux .deb + .rpm (amd64) (push) Successful in 11m52sRelease / Linux .deb + .rpm (arm64) (push) Successful in 12m42sRelease / Linux AppImage (aarch64) (push) Successful in 11m36sRelease / Linux AppImage (x86_64) (push) Successful in 10m41sRelease / Cosign sign artifacts (push) Successful in 26sRelease / Forgejo Release (push) Successful in 38sreleased this
2026-08-14 10:47:46 +00:00 | 0 commits to main since this releaseA hardening release, and a thank-you. Credit where it is due: Distortions of
M45Core / StratumStats read our source and reported the denial-of-service
weakness fixed below — exactly the kind of outside scrutiny an open-source
pool hopes for. Thank you.Fixed
- Rejected-share recording can no longer be used to overwhelm the pool.
Every rejected share used to spawn its own detached task that immediately
wrote to SQLite. Junk shares arrive at wire speed on an already-authorized
connection — submit has no rate limit (connect and auth do) — so an
attacker sending stale or invalid shares could pile up unbounded tasks at
the database writer. A rejected share now costs two in-memory counter
increments; a daemon loop flushes the coalesced deltas every 2 seconds as
a single transaction (final flush on shutdown, re-queue on flush errors).
Both Stratum V1 and V2 feed the same buffer. Buffer memory is bounded by
the auth rate limit. The stratum-v1 module doc also claimed submit was
rate-limited; it never was — the doc now describes the real protections. - The 60-second network-stats poll no longer trips over Bitcoin Core's
connection timeout. Core closes idle RPC connections after 30 s
(rpcservertimeout); our HTTP pool kept them for 90 s, so every
getmininginfopoll landed on a dead socket, failed, and burned a retry
(~500 warnings/day on the reference deployment). Pooled connections are
now dropped after 20 s. No correctness impact — the retry always
recovered, including forsubmitblock— just a wasted round trip and a
noisy log, both gone.
dvb-WarpPool v1.25.7 — Downloads
Docker
git.warppool.org/dvb-projekt/dvb-warppool:v1.25.7(multi-arch amd64+arm64, ohne v-Präfix)Native packages
- Linux .deb: amd64 + arm64 →
apt install ./dvb-warppool_*.deb - Linux .rpm: amd64 + arm64 →
dnf install ./dvb-warppool-*.rpm - Linux AppImage: x86_64 + aarch64 portable
- Linux tarballs: x86_64 + aarch64 for manual installs
- macOS .dmg: added shortly after publish (built separately) — or build from source
- Windows .msi: paused since the forge migration (no Windows runner yet)
Signatures
SHA256SUMS+ cosign bundle (SHA256SUMS.bundle, project key)- SBOM (SPDX) for all dependencies
Verify (project public key
cosign.pubin the repo root):cosign verify-blob \ --key cosign.pub \ --bundle SHA256SUMS.bundle \ SHA256SUMS sha256sum --check SHA256SUMSFirst-time setup: run
dvb-warppool-setupfor the first-run wizard.Downloads
-
Source code (ZIP)
2 downloads
-
Source code (TAR.GZ)
2 downloads
- Rejected-share recording can no longer be used to overwhelm the pool.