satoshi
f47699d7b0
The previous fix relied on inspecting the existing cert for a subjectAltName extension to decide whether to regenerate. That works but is brittle — it depends on openssl text output format and on the assumption that SAN is the only thing that could go wrong. If a future client rejects us for some *other* missing extension, we'd be stuck on a bad cert again. Switch to an explicit cert version marker (TLS_CERT_VERSION). Any time we change the cert shape, we bump the version; the startup check regenerates whenever the marker file is absent or out of date. Upgrades self-heal on next boot with no introspection. Write the full extension set via an openssl config file instead of -addext flags. -addext is subtly different across openssl versions (in some builds the extension lands in the CSR rather than the cert). The config-file path is the documented, portable way to pin basicConstraints, keyUsage, extendedKeyUsage, subjectKeyIdentifier, and subjectAltName together. Also log the resulting extensions at startup so operators can verify cert sanity from the service logs without exec'ing into the container, and pin a modern TLS floor in stunnel.conf (no SSL3, no TLSv1, no TLSv1.1).
Kamado Pool — StartOS Packaging
StartOS 0.3.5.1 wrapper for Kamado Pool, a modern solo Bitcoin mining pool built on a patched fork of CKPool-solo with a Go middleware API and Svelte real-time dashboard.
Build
make
This runs deno to bundle the embassy TypeScript procedures, builds a multi-arch OCI image via docker buildx, and packs everything into kamado-pool.s9pk using start-sdk.
The build pulls KamadoPool source from a local sibling checkout (../KamadoPool by default) via a docker buildx named build context — no GitHub clone, no pinned SHA. If your checkout lives elsewhere, override it:
make KAMADO_SRC=/path/to/KamadoPool
Install
make install
License
GPL-3.0 — matches upstream Kamado and CKPool.