Get started

SysWarden v4.10.4 is a stable IVV-validated intermediate release, published on 10 October 2026. Begin with the public release and an explicit recovery plan. A local source build has its own identity and does not inherit the release verdict.

1. Choose your path#

The package matrix is Linux AMD64/x86_64: DEB, standard RPM, an opt-in package-owned RHELPO RPM, and APK. The RHELPO artifact is a separate integration profile, not a generic replacement for the standard RPM.

2. Prepare recovery first#

Use a dedicated test host before changing production. Preserve configuration, persistent lists and required audit evidence. Verify a complete recovery snapshot and an independent console. Record the current package and operating-system versions. Keep an operator session open while applying firewall changes.

Read the exact configuration and package lifecycle contract before installation. SysWarden changes host policy; removing a package is not a full machine rollback.

3. Inspect the published inventory#

The release contains twelve files. GitHub-generated source archives are additional source downloads, not native packages.

Open the official v4.10.4 release. The signed tag points to c4bb1f7fdf48fd80652b6870af5babda0b16ad6e. The tested package product is 0e966d409b6b9d19116597edee1feafad0c83688, linked by the protected acceptance plan and source continuity assessment.

4. Verify before installing#

A checksum detects an unexpected byte change. It does not, by itself, establish who produced a file. Verify the release origin, package-family signature and applicable signed update metadata using independently trusted keys. Use the version-specific authentication procedure.

For an independent provenance check with an already trusted GitHub CLI, this example verifies the DEB against the expected repository, workflow and exact publication commit. Run it in the directory containing the downloaded package:

gh attestation verify syswarden_4.10.4_amd64.deb \
  --repo duggytuxy/syswarden \
  --signer-workflow duggytuxy/syswarden/.github/workflows/release-manager.yml \
  --source-digest c4bb1f7fdf48fd80652b6870af5babda0b16ad6e \
  --signer-digest c4bb1f7fdf48fd80652b6870af5babda0b16ad6e \
  --source-ref refs/tags/v4.10.4 \
  --deny-self-hosted-runners

This provenance check complements native package authentication. It does not enroll keys or install software. Stop on a mismatch and preserve the diagnostic output.

Verify the complete checksum inventory using the publication record and exact-tag Sigstore verification command. Workflow provenance authenticates the manifest; it does not assert that every deployment environment is supported.

5. Install for your exact environment#

Use the authenticated package matching your distribution and selected profile. Consult the package lifecycle reference and RHELPO profile before changing the host.

The imported deployment tutorial is explicitly based on v4.04.3. Its pinned commands and inventories remain historical. Do not replace version strings in those commands and assume the result is a reviewed v4.10.4 migration.

After installation, inspect the installed command help, validate the configuration and verify the services and actual firewall state. Test the intended access from a second authorized session. If a check fails, preserve the failure and use the complete recovery point.

Read IPv6 and administrator access before testing address and route renewal on a representative host. For downloader messages, use feed availability diagnostics.

Recover historical WireGuard state and remove packages#

Use the historical recovery and removal guide for the separately authenticated recovery executable, old wg0 retirement, recognized unmanifested current VPN migration, and half-configured package recovery. Retirement and preservation are separate operator decisions with fresh reviewed plan digests.

Keep configuration, ownership evidence and removal barriers until verified cleanup completes. Use the native package manager for package installations: apt-get remove or apt-get purge, dnf remove, or apk del. Direct CLI uninstall refuses native package registration before deleting product files. The guide explains shared firewall and historical Fail2ban boundaries, administrator retention, private backups and verification after reload and reboot. Rebooting alone does not restore a missing registered package payload.

6. Ask for help with useful evidence#

Join the SysWarden Discord community. In help-fr or help-en, include the release, operating system, package family, minimal reproduction and anonymized logs. Remove tokens, keys, passwords and private information. For a suspected vulnerability, use the security policy instead of a public support ticket.

What the release proves#

All fifteen protected Patch IVV checks passed. Fresh signed-package observations cover Debian 13 migration from v4.10.3, VPN continuity, separate removal and reinstallation paths, and AlmaLinux 10.2 installation, upgrade, IPv6 renewal, firewalld reload and reboot while preserving administrator authority. Optional package-owned RPM recovery and bounded filtering performance have their own checks. Historical support keeps its original identity. APK has signature, build and payload verification without a fresh Alpine lifecycle. This is not an all-platform or HA endurance claim. Read the exact acceptance scope.