main
5
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 ReactorcoremeltdownandClaude Opus 5.5
|
4ffc434b1b |
Keep server data in an encrypted database, and harden every part
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> |
||
|
ReactorcoremeltdownandClaude Opus 5
|
e0977a9241 |
Let an admin delete a vault, behind their own password
ci/woodpecker/push/build Pipeline was successful
The web interface could create a vault and never remove one, so the only
way to undo a mistake was the CLI. There is now a Delete link on every
vault you administer, leading to a page that says what is about to go —
owner, versions stored, grants pointing at it — and asks for your
account password before it goes.
The gate is re-authentication, not a confirmation checkbox. A session
token is enough to read and write a vault; it should not be enough to
erase every version of one, because a session is what an unlocked
laptop leaves lying around. The one-time code is required too when the
account has one enrolled.
It lives in confirmDeletion, so the rule holds wherever deletion is
reachable: DELETE /api/v1/databases/{id} now takes {password, totp?}
and answers 401 without it, and keeporg db -delete prompts. That is a
breaking change to the endpoint, which is why the server goes to 0.7.0
and the desktop clients to 0.4.0.
An account that signs in only through an identity provider has no
password to type. Rather than lock those deployments out of deleting
anything, they confirm by typing the vault's exact name — the weaker
gate, and deliberately the fallback.
Deleting takes the record, its grants, every stored version and the key
a merge vault left with the server, and tells the watchers over SSE.
Copies already in people's mirror directories stay where they are: the
server stops tracking a vault, it does not reach into anybody's home
directory.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
 root
|
7eed722ff5 |
Fix single sign-on from the web, and make passwords changeable
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. |
||
|
root
|
a9308a3e89 |
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. |
||
|
root
|
4d0d53ff04 |
Add client engine and desktop CLI that mirror KDBX files
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. |