Verify before you boot.

Every host Imager package is publisher-signed. Its embedded installer catalog authenticates the exact URL, compressed-image hash, expanded-image hash and byte size before writing. Manual installer downloads also carry an adjacent SHA-256 checksum.

Verify Tilo Imager first

Windows verifies the Authenticode publisher before opening the setup executable. macOS verifies the Developer ID signature, notarization ticket and stapled result. Linux downloads include an adjacent armored .asc signature and .sha256 checksum; verify both with the Tilo release key.

No public release is available yet. Verification files and the release link appear only after the signed matrix passes promotion. Unsigned CI artifacts are not substitutes.

Linux signature and checksum

Import the published Tilo release key, compare its fingerprint with the independently published fingerprint, then verify the downloaded Flatpak, AppImage, or portable tarball and its adjacent checksum:

gpg --show-keys --fingerprint tilo-release-key.asc
gpg --import tilo-release-key.asc
gpg --verify tilo-imager-linux-ARCH.flatpak.asc tilo-imager-linux-ARCH.flatpak
sha256sum --check tilo-imager-linux-ARCH.flatpak.sha256

# For another Linux format, replace .flatpak with .AppImage or .tar.gz.

Verify the installer medium

The signed Imager contains the release catalog. It accepts only the official HTTPS origin, bounds the transfer and expansion to the catalogued sizes, and checks both SHA-256 values before the drive selector can use the image. A manual download can be checked for corruption with its adjacent file:

sha256sum --check tilo-installer-linux-ARCH.img.zst.sha256

For an authenticated manual workflow, compare that digest with the catalog embedded in a verified Imager build.

If either check fails

Do not write, import or boot the image. Delete the failed files, check that you are using the official download address, and download them again. If a second verification fails, report the release rather than trying another mirror.

What happens after verification

The booted system verifies its signed image when it updates and keeps the previous deployment available for rollback. Verification does not replace a backup of your work and does not prove that every program inside an image is harmless. It establishes exactly which release you received; application confinement and permissions limit what runs afterwards.

How the running system limits authority