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: two questions about operating this turned up two gaps. "Where do I get
the admin password" had no answer once the line scrolled out of the log,
and "how do I set up OIDC" ran straight into a sign-in link that could not
work.
What:
- /oidc/login with no parameters now signs a browser in and ends in a
session cookie. It previously required the user code of a waiting client,
so the link on the web sign-in page always failed. With a code it still
approves a device, and the two paths no longer overlap: an empty user
code matches no pending device.
- POST /api/v1/auth/password, `keeporg passwd`, and a form on /web/vaults.
Changing a password requires the current one, and the one-time code when
a second factor is enrolled, and revokes that account's other sessions.
Until now nothing could change a password, which made the advice printed
at first start impossible to follow.
- keeporgd -reset-admin, for when that first password was not kept: a new
one printed once, any second factor cleared, sessions revoked. It writes
the state document directly and says to stop the server first.
- The client read stdin through a new buffered reader per prompt, so the
first prompt swallowed the rest and anything asking twice could not be
scripted. One shared reader now. A prompt for a password being set no
longer reads $KEEPORG_PASSWORD either; that variable holds the password
you sign in with, and taking it here would have set the new password to
the old one.
- HANDOVER gains a first-sign-in section and an OIDC setup section covering
the redirect URI, the config block, both entry points and how an identity
becomes an account.
Proved: OIDC now has tests, against a stub provider that serves discovery,
authorization, token and userinfo. They cover the web sign-in that was
broken, device approval, linking an existing account by username, the
refusal when auto_create is off, and a forged callback state. Eight more
cover the password change. Checked by hand with the real binaries: the
first-start password logs once and works, -reset-admin replaces it while
the old one stops working, and `keeporg passwd` changes it from a pipe.
Server 0.5.0, desktop clients 0.3.0.
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: 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