Storage. The server keeps its data in SQLite (a file in the data
directory, the default) or PostgreSQL (database, KEEPORG_DATABASE_URL or
-database). Every row, the KDBX versions included, is sealed with
AES-256-GCM under a key derived from the master key and named by an HMAC.
The master key is required to start and a different one is refused. A data
directory from 0.10 or earlier is imported on first start. Several servers
may share one PostgreSQL database. Go goes to 1.26 for the pure-Go
drivers (modernc.org/sqlite, jackc/pgx).
Hardening, after an audit of the server, both clients and the deployment:
- Single sign-on approves a device only after an explicit Approve in the
browser that started it, bound by a cookie and PKCE; identities are never
linked by username, by verified email only when allowed, never to admins.
- Sign-in attempts are limited per address and per account, passwords are
checked outside the store lock with uniform timing, one-time codes work
once, and starting two-factor needs the password.
- Merge vaults bound KDF parameters, payload size and XML shape, check
pushes before storing them, and run at most two merges at once. A version
is written in the same transaction as its metadata.
- Tokens in URLs only on the event stream, which ends on revocation; CSP,
frame-ancestors, no-store and HSTS; sign-in CSRF; 404 for databases
without access; new trusted_proxies.
- Clients open only the server's approval page, keep case-variant and
retired file names apart, never overwrite a save made during a pull,
require https except locally, send the stream token in a header, bound
their reads and escape notifications and terminal output.
- The .deb creates the master key, systemd is sandboxed further, nginx sets
modern TLS and HSTS, and CI deploys from main only.
Server 0.12.0, desktop 0.6.0, Android 0.4.0 (versionCode 4).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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 server is a single static binary with no dependencies, so its
container should be nothing but that binary. Shipping one also makes the
master key easy to lose, which needed handling rather than documenting.
What:
- Dockerfile: two stages, runtime is scratch plus the binary and a CA bundle
for reaching an OIDC provider, running as uid 65532. About 9 MB. The build
stage copies only go.mod, cmd/keeporgd and internal, so client or docs
changes do not invalidate it.
- The image has no shell, so HEALTHCHECK runs `keeporgd -healthcheck`, a new
flag that probes /healthz on the configured address and exits non-zero
with a reason. podman needs --format docker to keep the healthcheck at
all, which the Makefile passes when it picks podman.
- New -master-key-file flag, so a mounted secret works without a config file.
- The server now checks at startup whether the master key still opens the
stored vault keys, and says so. Without it, a container restarted without
its key discovers the problem one failed merge at a time.
- make docker, docker-run and docker-save; a compose example with read_only,
cap_drop ALL and no-new-privileges.
- The client and the server now version independently, so their Debian
changelogs are split per package and `make changelog` takes PKG=.
Server 0.3.0; the clients stay at 0.2.0.
Proved: built with podman and run. The container serves /healthz and /web,
its own healthcheck reports healthy, and a vault created through it was
edited from the same base by keepassxc-cli twice, merged by the server into
version 3, and read back with both entries intact. Restarted without the
master key it warns "1 of 1 stored vault keys do not open with this master
key" and answers a merging push with 409 merge_failed, leaving the vault
untouched; restored, it logs "1 vault keys available for merging" and merges
again. The same key supplied through -master-key-file from a mounted file
works identically. Both .deb packages build with their own changelog, and
make check is clean.
root