Every release signed, tested and accounted for
Packages now carry a signature, a bill of materials and a record of what they were built from - and a release is refused unless the fuzz tests, the upgrade tests and the vulnerability check all pass on the exact source commit.
A customer installing Xi-Batch or Xi-Text has always been able to ask two questions: what is in this package, and is it the one you built? Both now have answers that do not depend on taking our word for it.
What ships with every package
Every released package and tar carries a detached signature from Xi Software's release key, checked before release, with the public key published. Beside it is a CycloneDX 1.5 bill of materials: the package, its platform and SHA-256, the build OS, compiler and base image, and the libraries it links. The build record names the source commit, the toolchain version, the base image digest and the build reference.
Binaries are built with PIE, full RELRO, stack protector and fortified calls, and each package is checked for them before it can be released.
What a release has to survive
A release is not a build that compiled. Before anything ships:
- Fuzz testing runs against the schedulers' and spoolers' message handling and the API. A final release is refused unless the record for the exact source commit is clean. Ten targets as of 3 October.
- Upgrades are verified, not assumed. The previous release of the line, and the oldest release we hold, are installed in a clean systemd container and upgraded to the package under test, checking the service, configuration, licence and spool all survive.
- A known vulnerability in a linked library blocks the release. The build container checks what a build links against the distribution's security advisories; a pending security fix stops the final.
And the bytes that were tested are the bytes that ship: a verified pre-release is kept, and the final re-packages it rather than rebuilding.
Why now
The reporting duties of the EU Cyber Resilience Act, Regulation 2024/2847, began on 11 September 2026. Rather than treat that as paperwork, we rebuilt the release path around it over the first three days of October - signing, bill of materials, provenance, mitigations, vulnerability checking, fuzzing and upgrade verification.
The first visible result arrived the same week: the fuzz tier found two faults in the handling of messages between linked hosts, and they were fixed and released as XI-SA-2026-001 and XI-SA-2026-002 before any customer met them.