Skip to content

v1.6.0

Choose a tag to compare

View all tags
@mr-grj mr-grj released this 13 Oct 10:04
· 59 commits to master since this release
v1.6.0
d7bc836

Unlocking with a session is now the only way in: the vault key never leaves the server, for any client. This retires the compatibility path for v1.4.x apps and CLIs that v1.5.0 announced. Your vault, its database and your backups stay exactly as they are.

Upgrading

  • Update as usual, by hand or with one click. One-click updates work as in v1.5.1, with the same updater: there is nothing new to install. No database migration runs, and everyone is asked to unlock once, as after any update.
  • Nothing is converted. The database, the encryption and the backup format are unchanged, and backups made by earlier releases restore as before.
  • Use a CLI from v1.5.0 or newer. The CLI bundled in the backend image (./cip) is always current. A CLI from v1.4.x stops with a message asking you to update, and changes nothing.
  • Browser tabs left open since v1.4.6 or v1.4.7 reload into the current web UI on their next request; unlock again. Tabs from older releases show the refusal instead: reload them by hand.
  • Scripts that called POST /api/master_password/check or sent x-ciphermoth-key-derivation must unlock with POST /api/master_password/unlock and send the returned token in x-ciphermoth-session (deprecated since v1.5.0).
  • CIPHERMOTH_LEGACY_KEY_AUTH no longer exists. If your .env or compose file still sets it, it is ignored; you can delete the line.

Security

  • Removed the vault key protocol of v1.4.x clients, as announced in v1.5.0. No route returns the vault key or accepts it as a credential: unlocking with the master password opens a server-side session, and the session token is the only way in. Requests that still send the key in x-ciphermoth-key-derivation are refused (403, "code": "invalid_key") on every route, even together with a valid session token, before any route runs and without touching the session. POST /api/master_password/check answers 410 ("code": "upgrade_required") without checking the password, so it can no longer be used to obtain the key. Both answers say which client to update.

Removed

  • POST /api/master_password/check, the x-ciphermoth-key-derivation header, the legacy-key-auth feature in /api/meta, the CIPHERMOTH_LEGACY_KEY_AUTH setting, and the CLI's fallback to the vault key for servers older than v1.5.0. Against such a server, the CLI now stops and asks you to update the server (or use CLI 1.5.x).

Images

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

  • ghcr.io/mr-grj/ciphermoth-backend@sha256:a84c299c9b9db917d324b85db268c58e8f338df3077f076bdce5861575aa9b94
  • ghcr.io/mr-grj/ciphermoth-frontend@sha256:9a29b5cbd7181f9be270db9582c63a30b1af068f814f2ce9a9b272e56cf58596
  • ghcr.io/mr-grj/ciphermoth-updater@sha256:e967d9cfc32aca3e8372cb6d853a057e2ee353ec8e6826759b23c271afc798a0
Assets 2
Loading