KalderaCompute the hash of your file
On Windows, run Get-FileHash in PowerShell. On Linux and macOS, run sha256sum or shasum -a 256. Compare the output with the matching line in SHA256SUMS.txt.
Security / Verification
Trust the file you installed, not the page it came from
Every KalderaShield release publishes SHA-256 checksums and updater signatures. Verifying takes one command. It is the difference between running a file that someone mirrored with modifications and running the file the pipeline built.
What is published
Three layers of artifact evidence
SHA-256 checksums: every release ships a SHA256SUMS.txt next to the installers. The hash is computed by the release pipeline from the exact files it collected, and the collection step refuses artifacts that are not from the current build — a half-failed build cannot silently reuse an old installer.
Updater signatures: the Tauri updater bundles are signed with minisign, and the public key is embedded in the application itself. If an updater offer is not correctly signed, the app refuses it.
Release signatures: the tag-gated release pipeline signs every published artifact with cosign in keyless Sigstore mode, bound to the workflow run's OIDC identity. The pipeline also enforces a signing gate: Windows and macOS releases are blocked from publishing unless their artifacts are verified as signed.
One honest caveat: while no code-signing certificate exists, Windows installers you build or download from CI are unsigned by Authenticode. The signing gate keeps them out of public releases; if you obtain one through a build, verify the SHA-256 hash before running it.
How to verify in three steps
Check the checksum file itself
Checksums are published with the release they describe. If you download SHA256SUMS.txt from the official release and your installer's hash matches it, the file is the one the pipeline produced.
Let the updater verify itself
In-app updates are checked against the minisign public key compiled into the application. You never need to trust a downloaded update file manually.
Security Architecture
SHA-256
minisign
cosign
About SmartScreen and antivirus warnings
Expected, until a signing certificate exists
An unsigned executable with no download reputation is exactly the shape of file that Windows SmartScreen and antivirus heuristics warn about — this is a cost of having no certificate, not evidence of malware. Verify the SHA-256 hash, and if your antivirus still flags a hash that matches the published checksum, report the false positive to its vendor. The build workflow comments in the repository document this limitation openly.
Integrity
Published per artifact in SHA256SUMS.txt; the collector rejects installers older than the recorded build timestamp.
Updater authenticity
Updater bundles are signed at build time; the verification key ships inside the app and latest.json points to the signature.
Release authenticity
Published release artifacts are signed keylessly through Sigstore, bound to the GitHub Actions OIDC identity of the release run.
Frequently Asked Questions
About verification
Windows says "Windows protected your PC". What do I do?
That is SmartScreen reacting to an unsigned file, not a virus report. Verify the SHA-256 hash against SHA256SUMS.txt. If it matches, the file is the pipeline's output; the warning disappears permanently once releases carry a signing certificate.
Where do I find SHA256SUMS.txt?
Next to the installers in every release, and on the download page's verification section. A checksum that arrives only through a chat message is not verification — use the published one.
Can I verify without trusting any downloaded file?
Build from source: the repository builds reproducibly with documented npm and cargo commands, and the local release script produces the same artifact naming with its own checksums.