All pages

Updates

Settings → Updates shows the running version, checks GitHub for a newer release, shows its notes and installs it. By default QKVM asks GitHub once a day and shows an Update button in the top bar when there is something new; installing is always your click, and asks for your password again.

  • What a check sends: one request to GitHub's public API for the newest release. Nothing about your KVMs. Turn the daily check off in the same place if you'd rather not.
  • How an install works: the release is downloaded, its signature and checksum are checked, and it is unpacked into data/updates/<version>/ next to the running version. QKVM then restarts itself on it.
  • Only signed releases are installed. The public half of the publisher's release key is built into the program, and a release that does not carry a valid signature is refused. A copy built without a release key tells you about new versions and leaves installing them to you, unless it is started with --allow-unsigned-updates, which accepts a release checked by its checksum alone.
  • If the new version won't start, QKVM goes back to the previous one by itself. python -m qkvm --roll-back does the same by hand.
  • It only replaces the program's own files. If a release needs a Python package you don't have, the app says so and you update with pip instead.

Publishing releases

Releases come from the GitHub repository named in DEFAULT_REPO at the top of qkvm/update.py, which is qkvm/qkvm. Until that repository has a release, the app says there is nothing newer.

  1. A fork that publishes its own releases sets DEFAULT_REPO = "owner/name". Use only a repository you control: whoever can publish a release there can run code on every copy that installs it.
  2. Make a signing key with python -m qkvm.release keygen release-signing.key, put the printed public key in RELEASE_KEYS, and keep the key file out of the repository (the .gitignore leaves *.key out). Copies built with it install a release only if it is signed with that key; a copy built without one does not install updates by itself. Either sign on your own machine (python -m qkvm.release sign release-signing.key SHA256SUMS) or store the key's contents as the RELEASE_SIGNING_KEY repository secret and let the workflow sign.
  3. To release: set __version__ in qkvm/_version.py, commit, and create a GitHub release tagged v<version>. .github/workflows/release.yml builds the wheel and attaches it with SHA256SUMS (and SHA256SUMS.sig).