Updates

Autonoma checks for updates in the background and applies them automatically.

Why updates are signed

The update path downloads an executable and runs it. Without verification that is a hole straight through the application, and “it came over HTTPS” does not close it — TLS authenticates the host, and the host is exactly the thing most likely to be compromised.

So every release is signed with an Ed25519 key that never leaves the machine that builds it, and the application refuses to run an update it cannot verify against the matching public key.

The check fails closed. A malformed signature, a missing key, an unreadable file and a forged signature all refuse. There is no path that shrugs and installs it anyway.

What you will see

  • Up to date — checked, nothing newer.
  • Update available — downloading, verifying, then applying.
  • No update source is configured — the honest answer when no release feed has been set. It does not claim you are up to date when it has not looked.
  • Signature does not match — the download was altered or corrupted. It is discarded, not installed.

Verifying by hand

Every release publishes the installer and a detached .sig beside it, and the download page lists the SHA-256 so you can check a download yourself:

Get-FileHash .\Autonoma-Setup-5.3.0.exe -Algorithm SHA256

If you are self-hosting the release feed

Publish the installer and its .sig together, side by side. Installed copies fetch the signature from next to the installer; publishing the .exe alone means every install refuses the update, which looks exactly like updates being broken.

The endpoint should answer with a version and either an asset list or a download URL.

Something here wrong or missing? Tell us — documentation that describes software that no longer behaves that way is worse than none.