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.
54 lines
2.6 KiB
Plaintext
54 lines
2.6 KiB
Plaintext
keeporgd (0.4.0) unstable; urgency=medium
|
|
|
|
* Read the master key from the file named by KEEPORG_MASTER_KEY_FILE, the
|
|
convention compose, swarm and Kubernetes use for a provisioned secret.
|
|
The file may hold base64 or exactly 32 raw bytes.
|
|
* Neither master-key environment variable is ever created by the server:
|
|
a secret that failed to mount is reported at startup and vault creation
|
|
is refused, rather than replaced with a new key that would open none of
|
|
the existing vaults. Only the configured master_key_file is created on
|
|
first run.
|
|
|
|
-- tiredsysadmin <rcmd@garage.rcmd.space> Fri, 30 Oct 2026 09:42:50 +0100
|
|
|
|
keeporgd (0.3.0) unstable; urgency=medium
|
|
|
|
* Container image: a scratch-based image of about 9 MB holding the static
|
|
binary and a CA bundle, running as an unprivileged user. It has no
|
|
shell, so HEALTHCHECK runs the binary's own -healthcheck probe.
|
|
* New -master-key-file flag, so a mounted secret can be used without a
|
|
configuration file.
|
|
* At startup the server now reports whether the master key still opens the
|
|
stored vault keys. A container restarted without its key would otherwise
|
|
discover this one failed merge at a time.
|
|
|
|
-- tiredsysadmin <rcmd@garage.rcmd.space> Fri, 30 Oct 2026 09:15:50 +0100
|
|
|
|
keeporgd (0.2.0) unstable; urgency=medium
|
|
|
|
* Server-side merging. A vault the server can open has its two concurrent
|
|
saves folded together in memory, by KeePass's own synchronization rules,
|
|
instead of one being refused. The losing version of an edited entry is
|
|
kept in that entry's history.
|
|
* New vault creation: a web interface at /web, and `keeporg vault -create`,
|
|
both of which build the KDBX file and set its password.
|
|
* Vault keys are stored encrypted under a master key in
|
|
/etc/keeporg/master.key, created on first start. Back it up separately
|
|
from /var/lib/keeporg.
|
|
* The KDBX 4 codec, its merge engine, and the ChaCha20, BLAKE2b and Argon2
|
|
it needs are part of the package; they carry no new dependencies.
|
|
|
|
-- tiredsysadmin <rcmd@garage.rcmd.space> Thu, 29 Oct 2026 17:28:45 +0100
|
|
|
|
keeporgd (0.1.0) unstable; urgency=medium
|
|
|
|
* First release.
|
|
* keeporgd: synchronization server with nested group access control,
|
|
invite-link and OIDC registration, built-in TOTP second factor,
|
|
versioned KDBX blobs and server-sent update notifications.
|
|
* keeporg: desktop client that mirrors assigned databases as ordinary
|
|
.kdbx files, pushes every save and applies remote changes, with
|
|
server-wins, client-wins and manual merge strategies.
|
|
|
|
-- tiredsysadmin <rcmd@garage.rcmd.space> Thu, 29 Oct 2026 12:00:00 +0000
|