[advisedwang]

> Devising a new schema based on SQLite would allow for current features that are being jerry-rigged into the attributes to have their own real place in the database

Perfectly possible with XML too

> An SQLite based store is one of the most tested and optimal formats for document and application storage

It's optimized for things that largely don't matter for password storage. The testing is admirable, but there's no issue of keepass clients crashing or corrupting data so again, not very relevant (probably because of low concurrency, simple writes etc).

> A switch this big is a major chance to fix the governance structure and align it more with a democratic consortium than a benevolent-dictator-for-life style of project management

You don't need a technical change to solve this. In fact, a fork that would fracture clients is the last thing you need when making governance changes.

> So many quality of life features can be added where the old schema disallowed it

All of the features they list can be achieved with an XML format. The format isn't what's holding them back.

[hollow-moe]

I don't know if this could count as "corrupting": I made the mistake of syncing my keepassxc database to my macbook with finder webdav client (nextcloud backend) it read the file alright but when I tried to write a new secret it helpfully wrote an empty file in place, wiping nextcloud file versions in the process. Thankfully, Nextcloud was smart enough to move the previous file in the trash bin and I could restore it. It seems keepassxc "save" procedure here was to delete the old file and replace it with a new one and something went catastrophically wrong in the process ? Looking at the settings there's is a parameter for this method for particular circumstances but I didn't enable it back then. Now I just have a second database only on this mac synced to icloud and never letting it near my nextcloud again.

[advisedwang]

I actually had a similar thing happen with gvfs-fuse (Google drive). It was a bug in gvfs using the quota usage of a file as it's file size (because libgdata didn't provide a method to get file size), but I was using a file shared to me so it had zero quota usage.

All of which is to say I would bet on something in the webdav-nextcloud line being at fault instead of keepassxc.

[ctoth]

> All of the features they list can be achieved with an XML format.

Not writing the entire database on every save?

[layer8]

Not a problem for XML per se (you can work with byte positions, and with fixed-size blocks to avoid resizing/relocation), but in the case of KDBX there is the issue that it is encrypted as a whole. Not encrypting as a whole, on the other hand, risks leaking more information about the contents, like you can see which parts/how much changed between one update and the next.

[rlpb]

I actually prefer this. It's how most user-facing file formats work. KDBX in particular is often used in conjunction with syncing software, and I don't want a half changed file to sync and then the connection to be lost. The usual paradigm of "write new file then move and replace over old file" works more safely for atomic changes.

[advisedwang]

That's not a feature, that's an implementation detail.