Skip to content

v1.5.1

Choose a tag to compare

@mr-grj mr-grj released this 13 Oct 05:44
· 63 commits to master since this release

A reliability release for one-click updates. Nothing changes in your vault or its database.

Upgrading

  • Update as usual. One click, or docker compose -f docker-compose.prod.yml pull && docker compose -f docker-compose.prod.yml up -d. Nothing changes in the database, and everyone is asked to unlock once, as after any update.

  • If you use one-click updates, update the updater once. It doesn't replace itself. After the update, the update dialog shows this command; run it once in your CipherMoth folder:

    docker compose -f docker-compose.prod.yml --profile autoupdate pull updater
    docker compose -f docker-compose.prod.yml --profile autoupdate up -d --no-deps updater

    Until you do, CipherMoth refuses one-click updates instead of risking your vault, and shows you the command again. Future releases that change the database will only install through the new updater.

  • If a newer release than 1.5.1 is already out when you read this, the old updater will offer that one instead. Set CIPHERMOTH_VERSION=1.5.1 in .env, run docker compose -f docker-compose.prod.yml --profile autoupdate pull and ... --profile autoupdate up -d, then update with one click. See docs/UPDATING.md.

Changed

  • One-click updates can now undo a failed database change. Before applying an update, the updater pauses writes (the API answers 503 for a moment), takes a database snapshot and checks that it restores exactly. If the new version, its database migration or its web UI doesn't come up healthy, it puts that snapshot back and restarts the previous version. Before, it kept going when its backup failed and could only switch the images back.
  • Interrupted updates finish safely. A crash, docker stop, reboot or power cut in the middle of an update is completed or rolled back when the updater starts again. If it ever cannot recover on its own, it keeps the API paused, says so in the app, and docs/UPDATING.md explains what to do (updater.sh retry or a manual restore).
  • Stricter checks. The updater also verifies the signature of the version it would roll back to, insists that the web UI (not just the backend) runs the new version, keeps its three newest snapshots, and ignores expired, repeated or malformed requests.

Added

  • GET /api/health reports the version, whether the database matches the release, and whether an update is in progress. The web UI serves /version.json.
  • A release that changes the database refuses to migrate while an older updater is installing it, so the first such release cannot be installed by an updater that could not restore your vault. Updating by hand is not blocked, but it has no automatic rollback, so back up first.
  • Release images carry an io.ciphermoth.min-updater-protocol label, and the updater refuses releases that need a newer updater.

Images

Signed with cosign by release.yml@refs/tags/v1.5.1, for linux/amd64 and linux/arm64:

  • ghcr.io/mr-grj/ciphermoth-backend@sha256:b6d67d0486ed5093c530f43fc2a22d010d5957091f4672f1eeacb7318903c811
  • ghcr.io/mr-grj/ciphermoth-frontend@sha256:8577c2cf80e9d87e5ee205fff2eaee6fefb20d349225ee364793a1914b4c59d0
  • ghcr.io/mr-grj/ciphermoth-updater@sha256:f42ce4defacf1687bb1031719921f6b5976168e7b31bda5b87ead320a382c49d