keepassxreboot
Remote Sync information overwritten
Have you searched for an existing issue?
- [x] Yes, I tried searching and reviewed the pinned issues
Brief Summary
Configuration for remote-sync is overwritten by remote, even if newer:
I am using the current 2.8.0 Version with remote-sync feature on macs. When changing locally the configuration for remote-sync for a DB. It is reset from the remote data, when I do a remote-sync. This is unclear (happens silently) and unexpected. At least this is my assumption of what's happening. In case this is relevant: I use this version on different macs, connecting to a single NAS, where the file is stored on webdav. I am changing from using local .netrc files (which require that the password to the NAS is locally stored), to a setup where the configuration is stored (using curl - --user) directly in the access commands.
Steps to Reproduce
- Have a working setup with a main keepass file on a remote host and synchronization set up for webdav, using curl with .netrc.
- Modify the curl command used for accessing the file in the remote synchronization (replacing -n by --user with password
- Make sure to safe the configuration, test the configuration
- Execute remote sync. Check the configuration for remote-sync: it has been reset to the previous state.
Expected Versus Actual Behavior
The update should not overwrite the configuration, because it is newer, but should use the newest one for the merged one. (Ideally, this would also be updated on the remote host. ) Alternatively: info that remote configuration not updated and on both sides everything preserved.
KeePassXC Debug Information
(below also surprise: even on ARM claims: x86_64)
KeePassXC - Version 2.8.0-snapshot
Build Type: Snapshot
Revision: f53c7e5
Qt 5.15.16
Debugging mode is disabled.
Operating system: macOS 14.7
CPU architecture: x86_64
Kernel: darwin 23.6.0
Enabled extensions:
- Auto-Type
- Browser Integration
- Passkeys
- SSH Agent
- KeeShare
- YubiKey
- Quick Unlock
Cryptographic libraries:
- Botan 3.6.1
Operating System
macOS
Linux Desktop Environment
None
Linux Windowing System
None
well, there are two Macs (one intel, one M1) and the NAS is a synology running the webdav. However, if I do it only between the intel mac and the NAS, I already get the settings reset.
Im not sure on your exact setup. Are you remote syncing to an existing database file that did NOT have remote sync configured already?
ah sorry: I basically had the same database on the NAS (WebDav) and locally. - I update my configuration for the WebDav server locally. (Modifying the command to directly give user:pwd instead of using netrc (but this is probably minor). I do the merge/remote sync (in this case the actual passwords contained in the DB are actually identical, the only difference is the settings). After the successful merge, the older configuration from the DB on the NAS has been merged again into the local copy, overriding the updated configuration. So, it is probably crucial that the remote DB also has information on the remote sync, because this is apparently where the old version is coming from.
It's a tricky problem because keepass did not add timestamp or deleted item information for database custom data in the kdbx spec. This causes us to be unable to merge (overwrite) individual custom data items. We added a custom timestamp that applies to all custom items, but that can cause odd problems like you witnessed.
Unfortunately, I have no deeper insight in the handling of the custom items and the time stamping. But what surprises me, is this: for testing I did put the identical file on the NAS. Then I modified the local version. Now upon sync (merge), the remote data (i.e., the older! data) is made the common data. I would have expected a) the new data to overwrite the old or b) not overwriting this kind of data. But not old overwrites new.
recently I discovered this KeeShare feature in KeePassXC.
My use case is exactly same at mentoned by @kschmid here: I have several machines that are running original KeePass (Windows and macos via Wine) in offline-first mode using sync triggers on open and close to perform the bi-directional record based sync against a master database stored on NAS. Also I sometimes add credentials to a local database when setting up machines/services while being offline. These changes are then merged next time the machine is online again. This offline-first approach is running for years without any dataloss or isues. Also this avoids any file conflicts you might get using cloud sync while an offline client is getting online syncing changes.
But now I started to look for other solutions since Wine (as it is now) is depending on Rosetta 2, which will be deprecated by Apple after macos 26. macos has 16kB pages and Windows ARM binaries are 4kB pages. So a big challenge for Wine to run Windows ARM binaries on Apple Silicon, which might be solved by running lightweigth Linux container with Wine on ARM insinde new macos 26 containarization; but sill many challenges...
So reading here about KeePassXC KeeShare feature triggers mixed emotions: a) I am super happy having found a KeePass tool that somehow supports my preferred offline-first approach with bi-directional sync to 2nd file location. b) triggers a major concern having not fully understood the robustenss and limitations the KeeShare bi-directional sync has. Also the Documentation is not clear to me if credential are not being removed at shared database if deleted. Control of shared items if moved outside of shared group is not clear to me.
From the documention it says:
KeeShare does not synchronize group structure after the initial share is created. At this time, KeeShare operates at the entry level; shared entries moved outside of a shared group are still synchronized.
Expected behavior:
- If I delete an item it should be deleted in the shared sync group as well.
- If I decide to stop sharing a specific credential by moving it to a non shared group it should be deleted in the shared database.
Next steps for me are to better understand what happened in detail maybe to reproduce or setup a testplan. Appriciate some dialog on the issues being reported to better understand the potential impact/data loss for my workflow.
@kschmid what is your take away from this or workaround? @droidmonkey does this trigger any potential improvements?
There are a boatload of KeeShare feature and bug requests, use the labels in search.
@moritzthecat There is not so much I can add here. - Here case is more complex than mine. I am basically working with a single group and thus had not to move things around or delete any keys. For the way I am using it, this seems actually pretty robust at this point and works well. - Also in cooperation with other clients (e.g., on mobile devices) that have no such capability and simply copy from the NAS.
glad to see offline-first bidirectonal sync in on milestone #2937 @droidmonkey in case testing support or other input is appreciated pls. let me know