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.
68 lines
3.3 KiB
Plaintext
68 lines
3.3 KiB
Plaintext
keeporgd (0.5.0) unstable; urgency=medium
|
|
|
|
* Single sign-on now works from the web interface. The link on the
|
|
sign-in page started a flow that only a waiting client could finish, so
|
|
it always failed; a browser sign-in now ends in a session cookie.
|
|
* New endpoint for changing an account password. It requires the current
|
|
password, and the one-time code when a second factor is enrolled, and
|
|
revokes that account's other sessions.
|
|
* New keeporgd -reset-admin, for when the password printed at first start
|
|
was not kept. It prints a new one, clears any second factor on that
|
|
account and revokes its sessions. The server must be stopped first.
|
|
|
|
-- tiredsysadmin <rcmd@garage.rcmd.space> Fri, 30 Oct 2026 10:45:31 +0100
|
|
|
|
keeporgd (0.4.0) unstable; urgency=medium
|
|
|
|
* Read the master key from the file named by KEEPORG_MASTER_KEY_FILE, the
|
|
convention compose, swarm and Kubernetes use for a provisioned secret.
|
|
The file may hold base64 or exactly 32 raw bytes.
|
|
* Neither master-key environment variable is ever created by the server:
|
|
a secret that failed to mount is reported at startup and vault creation
|
|
is refused, rather than replaced with a new key that would open none of
|
|
the existing vaults. Only the configured master_key_file is created on
|
|
first run.
|
|
|
|
-- tiredsysadmin <rcmd@garage.rcmd.space> Fri, 30 Oct 2026 09:42:50 +0100
|
|
|
|
keeporgd (0.3.0) unstable; urgency=medium
|
|
|
|
* Container image: a scratch-based image of about 9 MB holding the static
|
|
binary and a CA bundle, running as an unprivileged user. It has no
|
|
shell, so HEALTHCHECK runs the binary's own -healthcheck probe.
|
|
* New -master-key-file flag, so a mounted secret can be used without a
|
|
configuration file.
|
|
* At startup the server now reports whether the master key still opens the
|
|
stored vault keys. A container restarted without its key would otherwise
|
|
discover this one failed merge at a time.
|
|
|
|
-- tiredsysadmin <rcmd@garage.rcmd.space> Fri, 30 Oct 2026 09:15:50 +0100
|
|
|
|
keeporgd (0.2.0) unstable; urgency=medium
|
|
|
|
* Server-side merging. A vault the server can open has its two concurrent
|
|
saves folded together in memory, by KeePass's own synchronization rules,
|
|
instead of one being refused. The losing version of an edited entry is
|
|
kept in that entry's history.
|
|
* New vault creation: a web interface at /web, and `keeporg vault -create`,
|
|
both of which build the KDBX file and set its password.
|
|
* Vault keys are stored encrypted under a master key in
|
|
/etc/keeporg/master.key, created on first start. Back it up separately
|
|
from /var/lib/keeporg.
|
|
* The KDBX 4 codec, its merge engine, and the ChaCha20, BLAKE2b and Argon2
|
|
it needs are part of the package; they carry no new dependencies.
|
|
|
|
-- tiredsysadmin <rcmd@garage.rcmd.space> Thu, 29 Oct 2026 17:28:45 +0100
|
|
|
|
keeporgd (0.1.0) unstable; urgency=medium
|
|
|
|
* First release.
|
|
* keeporgd: synchronization server with nested group access control,
|
|
invite-link and OIDC registration, built-in TOTP second factor,
|
|
versioned KDBX blobs and server-sent update notifications.
|
|
* keeporg: desktop client that mirrors assigned databases as ordinary
|
|
.kdbx files, pushes every save and applies remote changes, with
|
|
server-wins, client-wins and manual merge strategies.
|
|
|
|
-- tiredsysadmin <rcmd@garage.rcmd.space> Thu, 29 Oct 2026 12:00:00 +0000
|