- #Keepassxc synchronization full#
- #Keepassxc synchronization code#
- #Keepassxc synchronization password#
And cloud credentials are one of those things for which you'd rather have a password you remember because well, you need them to access keepass database for one. And this is problem number two - in case I change my job and forget to disconnect cloud client before I return my equipment, I can consider my cloud credentials leaked, because I bet it's stored either in plaintext or not too hard to reverse encryption. For convenience reasons I'd rather have nextcloud client remember my password.This can be workarounded by putting keepass database in a dedicated folder. However I'd rather avoid downloading my personal files on my work PC. And nextcloud client will let me only sync entire folders, not single files (I imagnine other cloud clients work in a similar fashion). Keepass is not the only thing I keep on my nextcloud drive.There are two problems with this approach Fortunately unlike I do have admin access there so I can install, in my case, nextcloud client and be happy with the result. Neither method should be difficult, but method 2 is on the order of trivial.I'll also share my use case in case you guys reconsider. A simple setting "Reload database on detection of external changes" a la KeePassXC in method 2 or "Set up for remote distribution" wizard with explanations in 3b is what is required for normal users to adopt this. Method 3 is alluring, but it still requires the user to set up complicated triggers and this increases the total cost to ownership for the average user. I suggest methods 2 or 3b with a personal preference for the ease and simplicity of method 2. This can be mitigated by refusing to automatically reload if local unsaved changes are detected. A "Set up for remote ditribution" wizard in the program.įor method 2 the only risk I can foresee is if the user alters but doesn't save an entry on machine 1 then alters AND saves on machine 2. Basically putting it as core functionallity. Method 3 but without the need for the user setting up any triggers at all. Filesystem watch events can be used so that the filesystem doesn't have to be actively touched.ģb. Essentially Paul's method but augmented with a new type of trigger in KeePass that fires when a change to the change marker file. This would support a single user/multiple device model with excellent (though not quite perfect) safety, and it still allows the existing synchronization paradigm to be used for those with more complex needs.ģ. Adopt KeePassXC's methodology, which is not to synchronize "local" and "remote" databases at all but simply to have your single active database be the file which is shared and then to just have the program automatically reload it when it detects outside changes to the file. It's probably The Right Thing™ to do some day, but not something I would suggest today.Ģ.
However it is likely to be an iron clad PITA to do and not something I'm prepared to advocate since I'm not prepared to contribute.
#Keepassxc synchronization full#
This will support full automation of the above usage case, but also more complicated usage cases too.
#Keepassxc synchronization code#
Overhaul the synchronization code to make it not write to a file if there have been no changes. To make truly automated distribution there are a few ways I can see to move forward. With some rather minor changes to KeePass, it could be rendered unnecessary. The "near real time sync" example above nearly accomplishes this in a very complicated way. I believe this usage case is by far the most common one for those wanting to use sharing at all. The usage case I am targeting is of a single user distributing a single database to multiple devices. Obviously I am advocating for changes to make automatic distribution and uptake of remote changes possible. The idea of a distributed database was obviously in mind when synchronization was added, it's unfortunate that it was implemented in such a way as to preclude automated uptake of changes. This is unexpected and in a word unfortunate. Sync always results in saving both the target and active database whether there were changes in the database or not.
0 kommentar(er)
