# What is a signed release (code signing)?

> A signed release carries a digital signature that lets you check who published software and that it hasn't changed since. What signatures prove, and what not.

URL: https://crunu.com/learn/code-signing
Language: en
Updated: 2026-10-30

A signed release is a published version of a program, an installer, a binary or a web bundle, accompanied by a digital signature made with the publisher's private key, so that anyone with the matching public key can check that the files came from that publisher and haven't been altered since they were signed.

## What signing provides

NIST's white paper on code signing describes the two properties: "Digitally signing code provides both data integrity to prove that the code was not modified, and source authentication to identify who signed the code" ([NIST CSWP 5](https://csrc.nist.gov/pubs/cswp/5/security-considerations-for-code-signing/final)). It applies to "firmware, operating systems, mobile applications, and application container images", anything that must be "distributed and updated in a secure and automatic way to prevent forgery and tampering."

A common pattern for software downloads:

1. The publisher computes a checksum, such as SHA-256, of each file.
2. It lists the checksums in a manifest and signs the manifest.
3. The installer or updater downloads the manifest and signature, checks the signature with a public key it already trusts, and then checks each file against its checksum.

The public key has to come from somewhere you trust independently of the download, usually built into the previous version of the software.

## What signing doesn't prove

- **That the code is good.** It proves who signed it, not what it does.
- **That the build was clean.** A compromised build machine produces malicious code that is still correctly signed. [Reproducible builds](https://crunu.com/learn/reproducible-build) address that gap.
- **That the signing key is safe.** Anyone with the private key can sign. That's why release keys deserve the strongest protection you have, such as offline storage or an [HSM](https://crunu.com/learn/hsm), and why a leaked one has to be replaced in every client.

## Common mistakes

- **Fetching the public key from the same place as the release.** An attacker who controls the download controls the key.
- **Checking the checksum but not the signature.** A checksum from the same server only proves the download wasn't corrupted.
- **Accepting older signed versions.** A validly signed old release with known bugs can be offered as an "update" unless clients refuse to go backwards.

## Signed releases in Crunu

Crunu's agent and web app are released with [Ed25519](https://crunu.com/learn/ed25519) signatures. `crunu self-update` downloads the release manifest and its signature, requires a valid signature by one of the release keys built into the `crunu` binary, checks that the manifest is for the agent and the version you asked for, and verifies the binary's SHA-256 checksum and size before replacing anything. Without a named version it never installs a lower version than the current one; you can downgrade only by naming the version. A `crunu` built without a release key refuses to self-update.

```sh
sudo crunu self-update --version 6.0.1
```

The installer checks the binary's SHA-256 too, and the web app checks its own release signature; the local file `crunu.html` checks the site against the signed release. Together with the [reproducible build](https://crunu.com/learn/reproducible-build) of the web app, this is how Crunu lets you check the code that encrypts your secrets. The broader trust model is in [who can decrypt your secrets?](https://crunu.com/guides/who-can-decrypt-your-secrets).

## Sources

- [NIST CSWP 5: Security Considerations for Code Signing](https://csrc.nist.gov/pubs/cswp/5/security-considerations-for-code-signing/final), checked October 30, 2026.