krites update¶

What `krites update` does¶

Replace the running binary with a newer signed release. It checks the configured release source (this project's GitLab releases), downloads the archive, verifies it, swaps the binary in place, and re-runs krites init so your configuration stays compatible.

The studio surfaces the same thing — see Update krites.

Usage¶

krites update [flags]

Flags¶

Flag	Short	Default	What it does
`--version`	`-v`	latest	Update to a specific version instead of the latest
`--force`	`-f`	`false`	Update even when the check says you are current
`--from-file`			Install from a local `.tar.gz` release archive, with no network

Plus the global flags on every command.

Verification is fail-closed¶

An update whose signature is missing, malformed, or made by an unrecognised key is refused, not warned about. krites verifies an OpenPGP signature over the release's checksums.txt, made by a key held in AWS KMS.

Verifying only the SHA-256 in checksums.txt would be circular — the binary and the checksum that "proves" it come from the same place, so anyone able to publish a release controls both.

Key	Default	Effect
`update.require_signature`	`true`	Refuse an update with no valid signature
`update.require_checksum`	framework default	Checksum enforcement, independent of the signature
`update.policy`	compiled-in	`disabled`, `prompt`, or `enabled`
`update.check_interval`	24h	How often a background check runs (`0` = every run)

Setting update.require_signature to false downgrades verification to advisory. That is only sensible while diagnosing a broken release.

What to do when an update is refused¶

A refusal is a genuine signal. Before working around it:

Check the machine can reach openpgpkey.phpboyscout.uk — that is where the signing certificate is published via Web Key Directory.
Check the release you are updating to actually published a checksums.txt.sig.

Reinstalling from the published .dmg or tarball is the safe recovery: those carry the same signature and can be verified by hand against checksums.txt.sig.

Why an unreachable key server is tolerated but a mismatch is not¶

The signing key is resolved from two anchors: one compiled into the binary, and one published on the public internet over Web Key Directory. The embedded anchor always works, even offline, but can only be changed by shipping a new binary; the WKD anchor is what allows the key to be rotated or revoked without one.

Situation	Behaviour
The two anchors disagree	Always fatal. A mismatch is a tampering signal and no configuration suppresses it.
WKD is unreachable (outage, offline, DNS)	Falls back to the embedded anchor with a warning. A CDN blip must never block updating.

So "the crosscheck is not required" means unreachability is tolerated. It does not mean a disagreement is tolerated.

Updating without a network¶

krites update --from-file ~/Downloads/krites_Darwin_arm64.tar.gz

The archive still has to verify. --from-file removes the download, not the signature check.

What `update` does not do¶

It never updates on its own. A periodic check may notify you that a release is available; applying it is always an explicit action.
It does not touch your shoots. Updating replaces the program. Verdicts, edits, removals and exports are untouched. A release that changes how a signal is computed invalidates the analysis cache, so the next krites cull re-analyses — but it re-analyses from your originals, and your manual verdicts survive.
It does not roll back for you. To go back to an earlier release, name it with --version, or reinstall that release's archive.