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.
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.
Why: picking a winner is what a sync server does when it cannot read the
file. Once it can, the right answer is the union of both edits.
What: kdbx.Merge folds one database into another. Objects are matched by
UUID; the most recently modified version of each wins and the loser is filed
in the entry's history, so nothing is dropped. Deletions apply only when the
deletion is newer than the other side's edit, otherwise the edit resurrects
the object and the stale record is discarded. Groups keep their nesting,
objects move when the other side moved them later, database settings follow
Meta/SettingsChanged, and custom data and icons are unioned by key.
Attachments are remapped from the incoming pool into the target's, since an
entry that kept its old index would silently gain the wrong file.
Proved: twelve tests over independent additions, both conflict directions
with history, deletion, resurrection, nested groups, relocation, attachment
remapping, idempotence, order independence and settings. The last one
marshals a merged database and has keepassxc-cli decrypt an entry that only
ever existed in the incoming copy.
Why: merging two edits of a vault means decrypting it, so the server needs a
real KeePass implementation. Nothing else in this repository can be built on
guesswork about the format.
What: internal/kdbx reads and writes KDBX 4.0/4.1 with AES-256-CBC or
ChaCha20 payloads, AES-KDF or Argon2d/Argon2id derivation, and the ChaCha20
inner stream for protected values. ChaCha20, BLAKE2b and Argon2 are
implemented here, since the standard library has none of them and this
repository carries no third-party dependencies.
The XML payload is kept as a generic node tree rather than Go structs on
purpose: a merge server that dropped elements it did not model would silently
destroy data written by a newer KeePass. Anything unrecognised round-trips
untouched. Unsupported ciphers, KDFs and KDBX 3 files are reported as such
rather than guessed at, so a caller can fall back instead of losing data.
Proved: ChaCha20 against RFC 8439, BLAKE2b against RFC 7693, all three
Argon2 variants against RFC 9106. Round trips preserve unknown elements and
multi-line values; a wrong password, a flipped payload byte and a flipped
header byte are each rejected. Entry passwords appear nowhere in the file,
encrypted or merely compressed. And the part that actually matters:
keepassxc-cli 2.7.10 lists, reads and decrypts the protected values of a
vault this code wrote, including at the production Argon2d cost, and this
code reads back the file KeePassXC saves after editing it.
Why: the set has to be installable and publishable, not just buildable, and
the next person needs the reasoning, not only the code.
What:
- android/: Kotlin client with no third-party dependencies. A
DocumentsProvider publishes the mirrored databases to every file picker, so
KeePassDX opens them as ordinary documents; closing a file it wrote
triggers a sync. A foreground service holds the event stream open.
Mirror.decide transcribes the Go merge table, so both platforms resolve a
conflict identically.
- Makefile as the single entrypoint, with file targets so only what changed
is rebuilt: host and cross builds, both .deb packages, the macOS DMG with
its /Applications symlink, the Windows zip, the APK under its F-Droid
publishing name, and manual-only android-publish.
- versions.mk holds one version per platform plus the Android versionCode;
`make bump` and `make changelog` move them. Debian changelog is tracked.
- systemd units (hardened system unit for the server, user unit for the
agent), macOS bundle and launch agent, Windows Task Scheduler job.
- docs/HANDOVER.md on architecture and every decision that shaped it,
docs/PROTOCOL.md for the API, README for the quick start.
Proved: make check and make test-race both pass; built both .deb packages and
inspected their contents, built the Windows zip, cross-compiled all five
desktop targets, and exercised make bump. The Android module is written but
not compiled: no JDK or Android SDK in this environment, which HANDOVER.md
states plainly.
Why: a KeePass application must see an ordinary .kdbx file. A mirror
directory of real files gives that on every desktop platform without FUSE,
WinFsp or macFUSE, and without cgo.
What: internal/client holds the API wrapper, an SSE reader, and a mirror
agent whose entire policy is one pure decide() table: adopt, pull, push,
force-push, server-wins, restore or manual. Saves are detected by rescan,
remote changes arrive over the event stream, and every overwrite of local
bytes leaves a conflict copy. cmd/keeporg drives it: login (password, TOTP or
browser/OIDC device flow), run, sync, status, plus the group, grant, database
and invite administration.
Proved: go test ./internal/client covers the decision table and runs a real
server in-process for adopt, follow, server-wins, client-wins, manual,
read-only restore, server-side rename and event-driven update. Also smoke
tested live: built both binaries, bootstrapped a server, logged in, created a
database and adopted a local file.
Why: collaborative KeePass use needs one arbiter of "who wrote last" that
never sees a master password, plus access control that follows an org chart.
What: stdlib-only Go server. Metadata is a single JSON document with one
writer and atomic commit; KDBX payloads are versioned blobs on disk. Access
comes from a group tree where a grant on a group reaches every member below
it. Login is password+TOTP, invite links, or OIDC through a browser-approved
device flow. Pushes carry If-Match and are arbitrated by a per-database merge
strategy (server-wins by default). Updates are pushed to clients over SSE.
Proved: go test ./internal/... covers RFC 6238 vectors, ACL inheritance and
isolation, store rollback, blob pruning, every push verdict, and an
end-to-end HTTP pass over login, conflict, force, read-only grants, invite
redemption, TOTP enrolment, device login and the event stream.
root