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>
/web/account, offered to everyone, lists every browser and client signed
in as you, with when each was last used, and signs any of them out, or all
but the current one. It sets up, replaces and removes the second factor,
and holds the password form, moved from the vault page. Administrators can
sign a user out everywhere from the People page.
The API gains GET and DELETE /api/v1/auth/sessions and DELETE
/api/v1/auth/totp. Sessions are named by a digest of their token, never the
token, and record when they were last used. Replacing or removing an active
second factor now needs the password and a current code.
Server version 0.10.0.
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>
The image passes neither -config nor -url, so a deployment had no way to
set external_url and the server built invite links, device-approval pages
and the OIDC redirect URI on http://localhost:8765. The variable overrides
the configuration file and -url overrides it. The deployment values set it
to https://keeporg.tiredsysadmin.cc.
Also document every environment variable the server reads, and the
standard proxy and CA variables it honours for OIDC.
Server version 0.8.0.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Started without a command, keeporg now shows a padlock in the system tray
with a menu like midi-webhook's: a status line, the mirror folder, each
database with its state, Sync Now, browser sign-in and sign-out, the web
interface, the configuration, the log, Start at Login, About and Quit. The
commands are unchanged.
config.json now carries every client setting (device_label,
request_timeout_seconds, ca_file, log_file, notifications), is written in
full on first start and is reloaded by the tray when saved.
A lock in the mirror directory admits one agent at a time, since the tray,
`keeporg run` and a service unit could otherwise race each other.
The tray uses fyne.io/systray: pure Go on Linux, BSD and Windows, cgo on
macOS only. The server keeps no third-party dependencies.
Desktop versions go to 0.5.0.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The deploy pipeline watched a VERSION file that does not exist, so a
version bump built the image but never deployed it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
Running the server meant running the API by hand: invites, accounts,
groups and grants existed only as endpoints and CLI commands, so the
browser could create a vault and nothing else.
/web/groups walks the group tree and opens onto one group's members,
roles and vault access, including the grants it inherits from above and
where they come from. /web/users lists the accounts you may see, and
lets a server administrator disable, enable, clear a lost second
factor, promote, demote or delete one. /web/invites shows the
outstanding links with their use counts, issues new ones and revokes
them.
Every administrative change is now a function of the state and the
caller in admin.go, which both the JSON handlers and the forms call. The
alternative was a second copy of the permission rules behind the pages,
which would have drifted on the first change. The same move gave the API
the two verbs it was missing: DELETE /api/v1/invites/{token} and
PATCH /api/v1/users/{id}.
Account changes are server-administrator only. A group administrator
decides who reaches which vault; disabling an account or clearing
somebody's second factor reaches past the group they share. Disable and
delete revoke that account's sessions, and the three changes that would
lock the caller out are refused on their own account.
Pages go through webPage and forms through webForm, so the session and
CSRF checks cannot be forgotten on a new form. No page carries any
JavaScript.
Server 0.6.0.
Co-Authored-By: Claude Opus 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 usual way to hand a secret to a container is to mount it as a file
and name the path in the environment. Compose, swarm and Kubernetes all do
it that way, and it keeps the key out of the process environment and off any
disk the container can write.
What: the master key is now looked for in KEEPORG_MASTER_KEY, then
KEEPORG_MASTER_KEY_FILE, then the configured master_key_file. A secret file
may hold base64, with or without padding or a trailing newline, or exactly
32 raw bytes, because secret stores produce both.
Only the configured path is ever created, which is what keeps a plain
package install working with no setup. The two environment variables name a
key something else owns, so a missing one is reported and vault creation
refused. Minting a replacement there would be worse than failing: it opens
none of the existing vaults, and the mistake would otherwise surface one
failed merge at a time.
The compose example now provisions the key as a real secret rather than an
environment variable, and the Dockerfile and README show the same. Neither
names a version any more, so they stop drifting as the server is bumped.
Proved: unit tests for every source and precedence, all four accepted
encodings, and that a missing secret writes nothing anywhere. In real
containers: a podman secret carrying base64 survives a stop and start with
"1 vault keys available for merging" and merges a stale push afterwards; a
secret holding 32 raw bytes creates a vault; and a secret that failed to
mount is named in the startup log, with vault creation answering with the
three places a key may come from.
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: 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