WolfStack v25.27.0
v25.27.0: a container's WolfNet IP can no longer be hijacked by an old rule on a wider-than-/24 WolfNet, backup folder exclusions are editable in place, and the Unraid agent configures WolfNet on first run
klas's containers answered ping on their WolfNet IP but refused every
port, and only changing the IP fixed it. His diagnostic tarballs
showed why: his WolfNet is a /16, and every "the WolfNet subnet" in
WolfStack was the node's first three octets. A DNAT rule for a
container on another third octet was never recognised as ours, so the
rule from each previous deployment stayed ahead of the new one and
iptables kept delivering the IP to whatever container now held the old
bridge address — one that answers ICMP and nothing else. The network
is now read as address plus prefix length from wolfnet0 (config.toml as
fallback) everywhere an address is tested for WolfNet membership or a
"WolfNet subnet" rule is written, and steady state for a container's
DNAT is exactly one tagged rule pointing at its current address; any
other arrangement is replaced, so existing piles repair themselves on
upgrade. The legacy /24 MASQUERADE rules that would otherwise keep
winning are removed on wider networks.
Mancolt could see a folder schedule's exclusions in Edit Backup
Schedule but not change them: each folder now carries an editable
exclusion field, and a folder added to an existing schedule can bring
its own. Exclusions the backup would silently ignore (outside their
folder) are flagged as they are typed.
klas also asked for WolfNet to come with the Unraid agent. The binaries
already did; the config never had, because setup.sh's Unraid branch
exits before the step that writes /etc/wolfnet/config.toml on every
other platform. The agent now writes that same config on first run
(installer's address selection, key generation and defaults, step for
step), and the daemon it already supervises has something to start.
Reported-by: klas
Reported-by: Mancolt
Co-Authored-By: CodeWolf paul@wolf.uk.com
Co-Authored-By: IntelligentWolf Ltd paul@wolf.uk.com
Verifying this release
Each binary is signed via cosign keyless OIDC (no key distribution — signing identity is the GitHub Actions workflow itself, anchored to the Sigstore Fulcio CA and the Rekor transparency log) and ships with a SLSA build provenance attestation.
Verify the cosign signature:
cosign verify-blob \
--bundle wolfstack-x86_64.cosign.bundle \
--certificate-identity-regexp 'https://github.com/intelligentwolf/WolfStack/\.github/workflows/release\.yml@.*' \
--certificate-oidc-issuer 'https://token.actions.githubusercontent.com' \
wolfstack-x86_64
Verify the build provenance:
gh attestation verify wolfstack-x86_64 --repo intelligentwolf/WolfStack
Verify the SHA-256 checksum:
sha256sum -c SHA256SUMS
Artifacts
wolfstack-x86_64/wolfstack-aarch64/wolfstack-armv7— static musl binaries (Linux x86_64, ARM64 / Raspberry Pi 4+, and 32-bit ARM).wolfstack-<arch>.cosign.bundle— cosign signature bundle (cert + signature + Rekor entry).SHA256SUMS— checksums for both binaries.
For per-version history see CHANGELOG.md.