Merge concurrent saves on the server, with vaults created from the web
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.
This commit is contained in:
@@ -4,19 +4,29 @@ A synchronization adapter for KeePass. Your databases stay ordinary `.kdbx`
|
||||
files that KeePassXC, KeePass2 or KeePassDX opens directly; a server keeps
|
||||
them in step between everyone who has access.
|
||||
|
||||
The server never opens a database and cannot read one. Master passwords stay
|
||||
on the clients.
|
||||
When two people save at once, the server can **merge** both edits: it opens
|
||||
the two copies in memory, folds them together by KeePass's own rules and
|
||||
stores the result. Nothing is lost, and no one has to reconcile two files by
|
||||
hand.
|
||||
|
||||
Merging means decrypting, so a merge vault's password is kept on the server,
|
||||
encrypted under a master key held outside the data directory. That makes the
|
||||
server part of your trust boundary. Vaults on any other conflict strategy
|
||||
keep their key off the server entirely, exactly as before.
|
||||
|
||||
- **Server** (`keeporgd`, Linux): hosts many KDBX databases, controls access
|
||||
with a tree of user groups, accepts registrations by invite link or OIDC,
|
||||
and pushes updates to connected clients.
|
||||
merges concurrent edits, and pushes updates to connected clients. Its web
|
||||
page at `/web` is for creating a vault and setting its password.
|
||||
- **Desktop client** (`keeporg`, Linux, macOS, Windows, BSD): mirrors every
|
||||
assigned database into one directory as a real file, pushes each save and
|
||||
applies what others push.
|
||||
- **Android client**: the same, published to every file picker as a storage
|
||||
provider.
|
||||
|
||||
No third-party dependencies, no cgo, no FUSE.
|
||||
No third-party dependencies, no cgo, no FUSE. The KDBX 4 codec, including
|
||||
ChaCha20, BLAKE2b and Argon2, is part of the repository and is tested against
|
||||
both the relevant RFCs and a real KeePassXC.
|
||||
|
||||
## Quick start
|
||||
|
||||
@@ -30,13 +40,15 @@ KEEPORG_ADMIN_PASSWORD=dev-password-1 make run-server
|
||||
# in another shell
|
||||
build/linux-arm64/keeporg login -server http://127.0.0.1:8765 -user admin
|
||||
build/linux-arm64/keeporg groups
|
||||
build/linux-arm64/keeporg db -create "Team Vault" -group <group-id>
|
||||
build/linux-arm64/keeporg vault -create "Team Vault" -group <group-id>
|
||||
build/linux-arm64/keeporg run
|
||||
```
|
||||
|
||||
Then save a new KDBX database as `Team Vault.kdbx` in `~/KeepOrg` from your
|
||||
KeePass application. It becomes version 1 on the server, and every later save
|
||||
is pushed automatically.
|
||||
`Team Vault.kdbx` appears in `~/KeepOrg`; open it in KeePassXC with the vault
|
||||
password you just set. Every save is pushed, and a save that races with a
|
||||
colleague's is merged rather than refused.
|
||||
|
||||
Or open `http://127.0.0.1:8765/web` and create the vault from the browser.
|
||||
|
||||
## Packaging
|
||||
|
||||
|
||||
Reference in New Issue
Block a user