Verifying your download

What you check, and why

A NetEnds release reaches you as two files, the platform and the Gia package, downloaded through private links in an email from NetEnds. Three things protect them:

• The SHA-256 checksum of each file, printed in the email. It proves the download arrived intact, byte for byte.
• A SHA256SUMS manifest inside each file — one SHA-256 hash for every file in the package. It proves nothing inside changed after it was packed.
• A SHA256SUMS.sig signature inside each file — an Ed25519 signature over that manifest, made with a private key that only NetEnds holds. You verify it with the release public key, netends-release.pub, printed at the end of the email together with its SHA-256 fingerprint.

The checks prove different things, and one does not replace the other:

• Checksums prove integrity — no byte changed in transit, and your copy matches what was packed. If a download was cut short or a file was swapped, the check fails.
• The signature proves authenticity — the release came from NetEnds. A checksum cannot prove that on its own: anyone who repacks a file can recompute its manifest to match, and a checksum check would still pass. Only a signature made with NetEnds’ private key binds the release to us.

The public key reaches you in the email, not with the download. That separation is the point: a key that travelled with the files would prove nothing.

What the installers check for you

• The one-paste installer checks each download against the SHA-256 checksum it carries from the email before unpacking anything, and checks the fingerprint of the public key it writes out. It then hands that key to the offline installer.
• The offline installer (install_offline.sh) verifies SHA256SUMS before it loads any image, then the signature. It takes the key from --pubkey /path/to/netends-release.pub, or from a netends-release.pub placed beside the unpacked directories. It checks the Gia package the same way, with the same key.
• The updater (netends-update-offline.sh) applies the same rules to every release you apply later.

All three fail closed. A signed release with no key supplied is refused. Once a key is supplied, a release without a signature is refused too, because stripping the signature is how a tampered release would try to pass on checksums alone. A key found inside a release is never used.

Check by hand

Run these on the Linux host before you install, from the directory that holds the downloaded files.

1. Check each download against the email. The value printed must match the checksum in the email exactly:

   sha256sum <file>

2. Check the key. Save the key block from the end of the email, from its BEGIN line through its END line, as netends-release.pub, ending with a newline. The value printed must match the key fingerprint in the email:

   sha256sum netends-release.pub

3. Unpack, then check the signature and the manifest from inside each unpacked directory:

   tar -xf <file>
   cd <unpacked-directory>
   openssl pkeyutl -verify -pubin -inkey ../netends-release.pub -rawin \
       -in SHA256SUMS -sigfile SHA256SUMS.sig
   sha256sum -c SHA256SUMS

The signature check must print Signature Verified Successfully, and every checksum line must report OK. Both must pass: the signature covers the manifest, and the manifest covers the files. The signature check needs OpenSSL 3 or later (for -rawin); no network access is needed.

The paths in SHA256SUMS are relative to the unpacked directory, so run the check from inside it.

If a check fails

A failed check means the copy you hold is not the copy that was packed. The cause is usually an interrupted download or a damaged file, not an attack. Download again and check again. If it still fails, stop and contact support@netends.com with the version and the name of the file that failed. Do not install a release that does not verify.