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 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 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