Verify a release
The agent is installed by piping a script into a shell, on machines that are not ours, and then runs with a network capability. So a release is signed, and every installer checks the signature before it trusts anything.
Why a signature and not only a checksum
Section titled “Why a signature and not only a checksum”latest.json lists the SHA-256 of every release file. But it is served from the same host as the files: whoever could replace a binary there could rewrite its checksum in the same motion. A checksum proves a download was not corrupted; it does not prove it was not replaced.
So latest.json and checksums.txt are signed in the release pipeline with a key that never touches the server. The public half is built into both installers. A server compromise could serve a different binary — and the installer would refuse it, because the manifest would no longer verify.
What the installers check
Section titled “What the installers check”| Installer | Checks |
|---|---|
install.sh |
The signature of latest.json with openssl, then the SHA-256 of the archive |
install.ps1 |
The same, with the cryptography built into Windows |
Either refuses to install on any mismatch.
By hand
Section titled “By hand”Each release at https://www.infrality.io/releases/<version>/ carries:
| File | What it is |
|---|---|
checksums.txt |
SHA-256 of every file in the release |
checksums.txt.sig |
Its signature (ECDSA P-256, SHA-256) |
The GitHub release of the same version also carries a software bill of materials (*.sbom.json, SPDX) for each archive.
Save the public key — it is printed in install.sh as RELEASE_PUBKEY:
-----BEGIN PUBLIC KEY-----MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEwpIXrQUP1+nHtRj8veP0bgL2SktXxi2XSlkIGGnF5e57Xv8e63RI6IamR7Ie9odn8PLcu1U9hSj5kO9Sja2mYQ==-----END PUBLIC KEY-----Then verify the checksums file, and the download against it:
openssl dgst -sha256 -verify infrality-release.pem \ -signature checksums.txt.sig checksums.txt# Verified OK
sha256sum --ignore-missing -c checksums.txt# infrality-agent_<version>_linux_amd64.deb: OKOn macOS use shasum -a 256 -c checksums.txt --ignore-missing.
Reproducible builds
Section titled “Reproducible builds”Release binaries are built with a pinned Go toolchain, -trimpath and the commit’s timestamp, so two builds of the same commit are byte-for-byte identical. Every artifact is smoke-tested on its own platform before the release is published.