ead82dc777c08ab62c913230bf22b89c1deb8cc6
11
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 root
|
3a499532f3 |
Make the deploy stamp the version and fire on Go changes
Two things in the deploy did not do what they looked like: build-server passed --build-arg APP_VERSION, but the Dockerfile declares ARG VERSION. An unknown build arg is ignored with a warning, so every deployed image was stamped "dev": `keeporgd -version` and the image's version label both said so, whatever the tag claimed. The build pipeline's path filter listed 'VERSION', a file this repository does not have, and '*.go', which under doublestar matches only top-level Go files, of which there are none. So a push that changed only Go code or only the version did not trigger a build. Now versions.mk and '**/*.go'. Proved: built with --build-arg VERSION=0.5.0 and ran -version in the container, which now reports 0.5.0. |
||
|
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
|
9c459909c3 |
Take the master key from KEEPORG_MASTER_KEY_FILE
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. |
||
|
root
|
dacfe20494 |
Add a container image for the server
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. |
||
|
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
|
4d2f0b047b |
Add KDBX merge with KeePass synchronization semantics
Why: picking a winner is what a sync server does when it cannot read the file. Once it can, the right answer is the union of both edits. What: kdbx.Merge folds one database into another. Objects are matched by UUID; the most recently modified version of each wins and the loser is filed in the entry's history, so nothing is dropped. Deletions apply only when the deletion is newer than the other side's edit, otherwise the edit resurrects the object and the stale record is discarded. Groups keep their nesting, objects move when the other side moved them later, database settings follow Meta/SettingsChanged, and custom data and icons are unioned by key. Attachments are remapped from the incoming pool into the target's, since an entry that kept its old index would silently gain the wrong file. Proved: twelve tests over independent additions, both conflict directions with history, deletion, resurrection, nested groups, relocation, attachment remapping, idempotence, order independence and settings. The last one marshals a merged database and has keepassxc-cli decrypt an entry that only ever existed in the incoming copy. |
||
|
root
|
5d66871527 |
Add a KDBX 4 codec: read, write, create
Why: merging two edits of a vault means decrypting it, so the server needs a real KeePass implementation. Nothing else in this repository can be built on guesswork about the format. What: internal/kdbx reads and writes KDBX 4.0/4.1 with AES-256-CBC or ChaCha20 payloads, AES-KDF or Argon2d/Argon2id derivation, and the ChaCha20 inner stream for protected values. ChaCha20, BLAKE2b and Argon2 are implemented here, since the standard library has none of them and this repository carries no third-party dependencies. The XML payload is kept as a generic node tree rather than Go structs on purpose: a merge server that dropped elements it did not model would silently destroy data written by a newer KeePass. Anything unrecognised round-trips untouched. Unsupported ciphers, KDFs and KDBX 3 files are reported as such rather than guessed at, so a caller can fall back instead of losing data. Proved: ChaCha20 against RFC 8439, BLAKE2b against RFC 7693, all three Argon2 variants against RFC 9106. Round trips preserve unknown elements and multi-line values; a wrong password, a flipped payload byte and a flipped header byte are each rejected. Entry passwords appear nowhere in the file, encrypted or merely compressed. And the part that actually matters: keepassxc-cli 2.7.10 lists, reads and decrypts the protected values of a vault this code wrote, including at the production Argon2d cost, and this code reads back the file KeePassXC saves after editing it. |
||
|
root
|
a58fa6158d |
Make the Android app build, and fix what compiling it exposed
Why: the module was written but never compiled, so nothing about it was proved. Building it found a name clash and a theme that would have crashed every device below Android 10. What: - KeepOrgProvider.requireContext -> ctx(): ContentProvider gained requireContext() in API 30, and Kotlin refused the silent hiding. - The application theme was @android:style/Theme.DeviceDefault.DayNight, which is API 29 while minSdk is 26. Replaced with @style/AppTheme, plain DeviceDefault in values/ and DayNight in values-v29/. - Backup exclusions: data_extraction_rules.xml and backup_rules.xml exclude every domain for both cloud backup and device transfer. The session token authenticates as the user and the mirrored files are the organization's password databases; neither belongs in a backup. - User-facing strings moved from code into strings.xml, so the app is translatable. Layouts stay in code, as before. - mipmap-anydpi-v26 -> mipmap-anydpi (the qualifier is redundant at minSdk 26), and the redundant activity label is gone. - Lint is configured to write a text report, and `make android-lint` runs it; `make android` now fails with a clear message when ANDROID_HOME has no SDK. Proved: the unsigned release APK builds (656 KB), lint reports "No issues found", and the packaged DEX contains all 16 classes including every manifest component. Toolchain used: JDK 21, Gradle 8.10.2, SDK platform 35 and build-tools 35.0.0; on this arm64 host Google's x86-64 aapt2 runs under qemu-user-static with amd64 multiarch libraries, which android/README.md now documents. The app has still not run on a device: there is none here. |
||
|
root
|
0e83acb9b1 |
Add Android client, packaging, Makefile entrypoint and handover docs
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
|
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. |
||
|
root
|
8bbb3179a1 |
Add KeepOrg sync server: accounts, nested groups, versioned KDBX sync
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. |