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>
The Android app kept a pending browser sign-in in a thread inside the
login screen. Android often kills the process while the browser is in
front, so the approval reached the server but nothing collected it, and
the app came back signed out with nothing saved.
The pending device code is now kept in Prefs and collected whenever the
login screen resumes. The app passes return_url=keeporg://device-approved
when it starts the sign-in, and the server's approval page, after a
password or single sign-on, links back to it. Only the keeporg: scheme is
accepted. Against a server older than 0.9, which rejects the field, the
app retries without it.
Verified on an Android 15 emulator: approval collected after the process
was killed, and the fallback against the 0.8 server.
Server 0.9.0, Android 0.3.0 (versionCode 3).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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: 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.
root