Comment by advisedwang | Hacker News Reader

Comment by advisedwang | Hacker News Reader

> 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.

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.

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.

I sync'd this file using various means on different platforms, nextcloud apps on windows using virtual files and android with Storage Access Framework cloud integration, and on linux with rclone and somehow never had such a catastrophic issue

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

Not writing the entire database on every save?

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

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.

Whole-file encryption with authentication is also more tamper-resistant. Basically the only thing an adversary can get away with there is rolling back the entire file to a previous version.

Whereas, any incrementally encrypted format has the additional risk of piecewise manipulations. For example, while SQLCipher authenticates each page, it doesn't authenticate the entire file, allowing for pages to be deleted, reordered, or duplicated (though duplication is easy to detect since each page has its own IV). The end result will generally just be a corrupted database, which will probably get detected by PRAGMA integrity_check, but compared to KDBX, this will not be detected by default nor is it guaranteed to be detectable at all.

Another in place option is AES-encrypted ZIP. ZIP has the benefits that the Directory at the end of the file can also include piecewise metadata for full file validation.

A part of me wonders if the only real upgrade needed for the next "large file" KDBX relative format is from a GZIP stream of the XML plus attachments to a ZIP container of the XML with attachments in some folder structure combined with the choice of a good piecewise (modern) encryption for the ZIP container. (That is taking more cues from 7zip than from classic, now broken password-encrypted ZIP files.)

(Though as someone who tries to keep my KDBX files small, I think I'd still prefer the option of a whole-file encrypted format.)

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.

Reply on news.ycombinator.com