root
a9308a3e89
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.
KeepOrg for Android
A KDBX synchronization adapter with no third-party dependencies: the server
is reached with java.net.HttpURLConnection, JSON is parsed with the
platform's org.json, and the two screens are built in code. The release APK
is about 650 KB.
How a KeePass application sees it
KeepOrgProvider is a DocumentsProvider, so the mirrored databases appear
in every file picker under "KeepOrg". KeePassDX and Keepass2Android open them
like any other document. When the application closes a file it had opened for
writing, the provider triggers a synchronization pass, which is how a save
reaches the server.
SyncService is a foreground service that holds the server's event stream
open, so a change pushed by a colleague arrives without opening the app. The
user turns it on from the main screen; it is not started at boot.
Nothing the app holds may leave the device in a backup or a device transfer:
res/xml/data_extraction_rules.xml and res/xml/backup_rules.xml exclude
every domain. The session token authenticates as the user, and the mirrored
files are the organization's password databases.
The merge policy in Mirror.decide is the same table as the desktop client's
internal/client/decide.go. Keep the two in step.
Building
Requirements: JDK 17 or newer, Gradle 8.9 or newer, and an Android SDK with
platforms;android-35 and build-tools;35.0.0.
export ANDROID_HOME=$HOME/android-sdk
make android # unsigned release APK, named for the F-Droid repository
make android-lint # lint; the project is kept at zero findings
make android-publish
The Gradle wrapper is not committed, so the Makefile calls whichever gradle
is on PATH. Generate a wrapper if you prefer one:
gradle wrapper --gradle-version 8.10.2.
The release build is deliberately unsigned: the private F-Droid repository signs what it publishes.
Building on an arm64 Linux host
Google ships aapt2 for linux-x86_64 only, so an aarch64 build host needs to
be able to run it. Debian's own arm64 aapt2 is too old to read the API 35
android.jar, so run the official one through QEMU instead:
sudo dpkg --add-architecture amd64
sudo apt update
sudo apt install qemu-user-static libc6:amd64 libstdc++6:amd64 zlib1g:amd64
After that aapt2 runs transparently and the build needs no further flags.
Everything else in the Android toolchain (R8, the resource merger, zipflinger,
apksig) is Java and architecture-independent.
What is verified and what is not
The APK builds clean and lint reports no issues, and the packaged DEX contains every class the manifest names. The app has not been exercised on a device or emulator: there was none available. The first real run is where to confirm the picker integration, the save-triggered sync and the notification.