Why: the usual way to hand a secret to a container is to mount it as a file
and name the path in the environment. Compose, swarm and Kubernetes all do
it that way, and it keeps the key out of the process environment and off any
disk the container can write.
What: the master key is now looked for in KEEPORG_MASTER_KEY, then
KEEPORG_MASTER_KEY_FILE, then the configured master_key_file. A secret file
may hold base64, with or without padding or a trailing newline, or exactly
32 raw bytes, because secret stores produce both.
Only the configured path is ever created, which is what keeps a plain
package install working with no setup. The two environment variables name a
key something else owns, so a missing one is reported and vault creation
refused. Minting a replacement there would be worse than failing: it opens
none of the existing vaults, and the mistake would otherwise surface one
failed merge at a time.
The compose example now provisions the key as a real secret rather than an
environment variable, and the Dockerfile and README show the same. Neither
names a version any more, so they stop drifting as the server is bumped.
Proved: unit tests for every source and precedence, all four accepted
encodings, and that a missing secret writes nothing anywhere. In real
containers: a podman secret carrying base64 survives a stop and start with
"1 vault keys available for merging" and merges a stale push afterwards; a
secret holding 32 raw bytes creates a vault; and a secret that failed to
mount is named in the startup log, with vault creation answering with the
three places a key may come from.
Why: the point of a sync server is that two people can work at once. Picking
a winner was all this one could do while it could not read a vault.
What, end to end:
- A vault is created at /web or with `keeporg vault -create`: the server
builds an empty KDBX 4 file, encrypts it with the password from the form,
and stores it as version 1. An existing database can adopt a stored key
with `keeporg db -id <id> -store-password`, which is verified against the
stored file before it is accepted.
- A stale push to a `merge` vault is no longer refused. The server opens the
stored version and the pushed one in memory, folds them together, and
stores the re-encrypted result. Clients push as usual and pull what comes
back. Any failure answers 409 merge_failed and the client keeps its copy
aside, so a failed merge still loses nothing.
- At rest: vault contents stay KDBX-encrypted as always. A merge vault's
password is kept AES-256-GCM-wrapped under a master key that lives outside
the data directory, bound to the vault id, never returned by the API. A
stolen data directory is ciphertext; a stolen data directory plus the
master key is not. The server runs without a master key and simply refuses
to create or merge vaults.
This moves the server inside the trust boundary for vaults it can merge,
which is inherent to merging and is stated plainly in the README, the
handover notes and the web form itself. Key-less strategies are unchanged and
remain the default for a database created without a password.
Proved: two clients editing the same version are merged rather than refused,
the newer edit of one entry wins, a merge failure leaves the stored vault
untouched, `merge` is refused without a stored key, the wrapped key never
appears in state.json or the API, and the web interface rejects a form
without its CSRF token, withholds its cookie over plain http, and only offers
groups the user administers. Checked by hand against the real thing: a vault
created in a browser, edited by keepassxc-cli on two sides from the same
version, merged by the server, and both entries read back out with
keepassxc-cli. make check, make test-race, android lint and both .deb builds
are clean.
root