KeePass ecosystem has no sync protocol; the recommendation seems to be to have each client handle its own database as if no other device exists, and sync them out of band.

but what if there are conflicts? what if two devices are offline and update the database at the same time? is there any way to meditate this and merge the changes?

@sodiboo every record has some meta-data, so the easiest merge algo is just "choose the newest change"

@zimward yes, but is such a thing done in practice? at the end of the day, the recommendation i’m reading is to sync encrypted binary files via something akin to Google Drive or Dropbox. those services are inherently untrusted and do not know anything about individual records; nevermind the fact that they don’t care for particular file formats.

it’s not plaintext. can’t throw something like git on it.

obviously a merge is physically possible. but is that done? when i read “haha just put it in Dropbox 🤗” i hear “lmao good luck if it’s mutated in parallel”

@sodiboo not to my knowledge, you just get fucked if the DBs clash

@sodiboo Yeah, not a fan of it..... But also no other tool solves this while allowing me to run my own infra for this easily (or ideally have P2P sync) — Vi

@sodiboo i think the idea is that there is only ever one active client. if you get into concurrent writes it all falls apart

@zimward yaeah that’s a completely reasonable design decision BUT i would still expect it to know that there are other clients and perhaps do some kind of “lock” when mutating. or if it doesn’t automatically merge stuff; i would expect it to be able to ask me which changes to keep. sure, whatever, concurrent access is in fact niche because one human does not edit from multiple places at once. but one device might be offline as i’m using it! or it might otherwise fail to upload its changes for a multitude of reasons! maybe my sync service is offline but i keep using passwords for that time!

by the sounds of it, instead of showing me any kind of diff, it just dies upon the first sign of a conflict. this is also what amy says.

and that just seems. Extremely Poorly Thought Out for something so critical as a password manager? why is KeePass a de-facto protocol and a whole ecosystem that people love? why is this not Solved? why is this not one of the first things to Solve?

@sodiboo keepass was the first kid on the block so to speak and the current sync protocol was a tacked on after thought that i have only seen keepassxc implement. i would also not call keepass a protocol. its just a shared storage format which really boils down to encrypted xml

@zimward

its just a shared storage format

that’s what a protocol is! it’s the format which applications speak to each other in! KeePassXC, KeePassDX, original KeePass, all need to communicate because presumably the user has >1 device.

it’s not “really” a protocol in the sense that it wasn’t really intended for this; i agree. that’s why i described it as a “de facto” protocol. but it’s used for communication. so it is a protocol whether you like it or not. mainly for the reason that a password manager is something you need to have on every device.

of course, the KeePass database format is not a fully functioning protocol by itself, but rather just the file made useful by synchronization with an external provider. so really, the protocol is something like KeePass+Dropbox, as defined by the documentation

@sodiboo keepassxc has a merge function

@ielenia is there a standard way to sync which triggers this functionality upon conflicts? because from what i read on the documentation, you’re supposed to sync the database using methods that are “oblivious” to the actual password management? wouldn’t it still be a pain when there is a conflict, because I’d need to have both versions present next to each other (which might not be the case on like, a network drive)?

@charlotte @ielenia

it notices that the db has been modified in place then tries unlocking the new db with the cached key

hm. that sounds fine i guess, as long as both devices are online when it happens. but what if they’re not!

any synchronization that is asynchronous is quite easy to cause sync conflicts with

yes! exactly! and evidently, it is possible to merge conflicting changes at the application level but not if it’s an encrypted blob?

@charlotte @ielenia yes, that’s the problem! because then they can desync. and when back online, you’re likely going to have to pick just one version with your generic network sync, rather than merging changes, right?

@charlotte @ielenia yeah! but that seems… just like bad software design? especially for something critical like a password manager. data loss is very bad because then i’m locked out of an account! if i’m forced to discard one branch, that’s data loss!

that’s baffling to me! fym it doesn’t try to solve this! this is an important problem to solve. why is this a beloved ecosystem of software??

@sodiboo I think most password managers solve this by only allowing writes online and one at a time

Locking mostly solves this and for a password manager it’s probably fine

@sodiboo @charlotte syncthing doesnt delete your old copies, it just renamed them with the sync conflict info

@natty@astolfo.social @sodiboo@gaysex.cloud

currently use firefox for website logins. syncs to phone ff. Don't have a memorable password I use anymore.

@ielenia @charlotte hm. okay. that makes sense. that seems like a functioning sync setup without data loss.

@sodiboo I use Syncthing, which has a way to handle conflicts: https://docs.syncthing.net/users/syncing.html#conflicting-changes