SYSwarden.
A clearer name.
The same purpose.

01

A small change in lettering. A clear identity.

From today, the project is called SYSwarden. Three capital letters, followed by a lowercase warden. You will see that spelling across the website, documentation, diagrams, social images and the project's maintained presentation. The shield, the colours and the visual language stay familiar. This is a refinement of the name of the same open-source project.

I wanted to make that identity consistent as we work towards v5. A project becomes easier to recognise when its name is written the same way wherever people encounter it. A diagram, an installation guide and a shared article should all clearly belong to the same project.

The domain remains syswarden.io, and the repository remains duggytuxy/syswarden. Commands, package names and established technical identifiers continue to use their existing spelling. You do not need to rename a configuration directory because the public wordmark has changed. Historical evidence and signed release records keep their original identity.

02

The important work is still ahead of the release.

A clearer name does not finish a security product. The demanding part of v5 is proving how it behaves across the situations that operators actually face. A successful build is useful. A passing component test is useful. Neither, on its own, tells us that an upgrade, an interrupted operation or a removal will leave a host in the intended state.

That is where much of the work goes: installation and activation boundaries, upgrade and recovery paths, service reloads, reboots, and the preservation of administrator configuration. Removal deserves the same attention as installation. The product must remove what it owns while preserving unrelated rules, services and security protections.

The tests also need to challenge the unhappy paths. What happens when an input changes during an operation? When a process exits early? When an expected dependency is absent? When the machine returns after an interruption? We need observable outcomes, repeatable checks and evidence tied to the exact source and artifacts under review.

V5 remains in development. This naming update does not announce a release, completed penetration testing or final acceptance. It is a good moment to explain what is needed to get there.

03

The funding goal: EUR 3,500 to help finish v5.

I am asking for EUR 3,500 in donations to support the remaining work on SYSwarden v5. This is the funding target for this appeal, not an amount already collected. I am an independent maintainer, and the time and infrastructure needed for careful security engineering have a real cost.

The aim is to make room for complex tests, focused code review, scoped penetration testing, correction of the findings and validation. Funding can support temporary test environments and the engineering time needed to prepare scenarios, investigate failures, fix defects and rerun the relevant checks. It can also help bring another perspective to the parts of the code that most need scrutiny.

That does not mean EUR 3,500 purchases an unlimited external audit or guarantees every desired assessment. Independent review and penetration testing need an agreed scope, a suitable environment, available expertise and a realistic cost. I will distinguish work completed by me from work carried out independently, and report the scope actually assessed.

The principle is the same as in my earlier article about funding independent open-source security: donations support the work behind the software, including the less visible work that makes a release more defensible.

04

Test. Review. Challenge. Fix. Validate.

The route to acceptance is an engineering process. Complex lifecycle tests establish what the candidate does. Code review examines whether its decisions and trust boundaries are sound. Scoped penetration tests challenge those boundaries. Findings then need correction and retesting before they can contribute to a validation decision.

Since the November 4 policy update, every SYSwarden release follows IVV: Integration, Verification and Validation, including v5. Financial constraints led me to remove the separate full Qualification requirement. This appeal does not silently bring it back or rename incomplete evidence as a pass.

The acceptance decision must still identify the candidate, the checks required by its changes, the results and the remaining limitations. Excluded or untested scope must be visible. A failing required check remains a failure until resolved. The release must retain its artifact verification and protected acceptance requirements.

05

What support should make possible.

My priority is to use the available resources where they improve confidence in the release: difficult transitions, security-sensitive boundaries and reproducible recovery. I will communicate the work performed and its limits through the project. If a planned activity is unaffordable or cannot be completed, that constraint needs to be stated rather than hidden behind a reassuring label.

I will not turn this funding target into a release deadline. Reaching it would help the work move forward; it would not make unresolved defects disappear or automatically approve a candidate. The decision to publish must follow the evidence.

Donations are voluntary support for an independent open-source project. They are not a support contract, a service-level agreement, a certification or a promise of a particular release date. The project remains open to people who cannot contribute financially.

06

Money helps. Careful contributions matter too.

If you can help financially, thank you. If you cannot, a reproducible bug report, a focused review, a clearer explanation or a test scenario from a disposable environment can be valuable. Start with the documentation and the repository, or discuss an idea in the community. Please keep credentials and private operational evidence out of public reports.

Sharing this appeal with people who care about independent Linux security is another way to help. The new spelling is a small, visible step. Finishing v5 responsibly is the substantial work behind it. That is what I am asking you to support.