Update crunu with self-update

crunu self-update replaces the crunu binary with another version from a signed release. It refuses anything it can't verify.

crunu self-update [--version VERSION] [--releases-url URL]

sudo crunu self-update --version 6.0.1

What it checks

1. It downloads manifest.json and manifest.sig for the version from the release directory.
2. The manifest must be exactly canonical JSON followed by one newline.
3. The signature must be a valid Ed25519 signature by one of the release keys built into crunu. A small-order key is rejected.
4. The manifest must be for the agent and for the version you asked for.
5. The binary for your platform must match the SHA-256 checksum and size from the manifest.
6. The new binary is started once with crunu version as a test.

Only then does it replace the current binary atomically: it writes a temporary file next to it and renames it. If the new binary doesn't start after the switch, the previous one is put back.

A crunu built without a release key refuses to self-update.

Choosing a version

Without --version, crunu reads the latest version from RELEASES_URL/latest, a file with one line. That pointer isn't signed, so crunu never installs a lower version than the current one when you don't name a version. You can downgrade only by naming the version explicitly.

The release directory comes from --releases-url, then releasesUrl in /etc/crunu/agent.json, then the address built into the release. That's the same address the installer uses.

Permissions and the service

You need write access to the directory of the binary, which means sudo for /usr/local/bin. If you installed with --user-install, run crunu self-update without sudo.

On a machine, restart the service after the update so it runs the new binary:

sudo systemctl restart crunu-agent

Package installs

A crunu installed from the .deb package is updated with apt or dpkg. crunu self-update refuses to replace it, so the package manager stays in charge of the files it installed.

When to update

The server tells agents the minimum agent version it accepts. A crunu older than that doesn't sync: the service explains why in its log, and crunu run exits with code 1. When the server is updated, update the agents too:

• installed by the script: sudo crunu self-update, then restart the service;
• installed with --user-install: crunu self-update;
• installed from the package: apt or dpkg;
• in CI: take the new version, install URL and both checksums from the CI setup block on the service token's page, and update the pipeline variables. See Any CI with a service token.

If you roll the server back to an earlier version, you don't need to roll back the agents. The older server doesn't raise the minimum agent version.

Install commands use the same checks

The install command shown in the web app contains the SHA-256 checksums of the install script and of the binary, taken from the release manifest. The web app checks the manifest signature with a key built into its own build before showing them. The installer then checks the binary against the checksum before putting it in place. The same applies to the CI wrappers, which check both the install script and the binary. See How encryption works for how signed releases fit into the wider picture.