Why the KeePass format should be based on SQLite

SQLCipher is not SQLite.

A key aspect of SQLite's development model is its proprietary test suite. As far as I can tell, the SQLCipher developers do not have access to those tests.

This is not to say they aren't doing the best with what they've got, but SQLCipher is a fork of SQLite, and the scope of the changes they must make, no matter how conservatively they try to make them, should lead to a full re-test of the entire product, which they cannot do.

EDIT: I don't want this to come off as spreading FUD. The SQLCipher developers do a good job of laying out their development methodology, the relative (un-)testability of their product vs. SQLite, and other tradeoffs pretty well in the repository's README: https://github.com/sqlcipher/sqlcipher?tab=readme-ov-file#sq...

The schema issues aren't solved by moving to sqlite, or the proposed solution is doable with XML too. I can see the same thing with the attributes (some described it as a shadow schema) happening in an attributes table just as easily. And in my experience relational schemas are a lot harder to modify than a document schema like XML.

EDIT: also you don't need to have just one password vault and I'd say you probably shouldn't, separate entries also assist with separation of concerns. This last adds a little overhead but is a reasonable workaround.

However on the whole I like sqlite for app persistence. It can, however, leak data (forensically) if not managed properly.

Is kdbx broken or has it been causing data loss? I've been using KeepassXC as long as it has existed and no issues for me thus far. If kdbx is not problematic for it's intended use then I think moving to SQLite just makes it more hacker friendly which I have no need for. I have no need for other applications extending the use of my passwords.

If anything, maybe give people the option to export to SQLite and then use that going forward but keep it entirely optional.

> So rather than risking sync issues uploading your 20MiB KDBX file on every minor change, you can upload just the 4KiB or so comprising that data.

Why is your KDBX file 20 MiB? It seems you are storing something that is not actually a good fit for a password manager, and expecting the entire world to change around you instead of storing those files in a more appropriate place.

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

Maybe it's irrational, and I cannot actually justify it (and of course safe writing is of primary importance), but somehow rewriting the whole file feels like a good thing for a secrets storage. Updating only part of a file obviously reveals something, even though it probably shouldn't matter if it doesn't reveal anything useful. But the default mode of thinking is we can never assume the leaked information cannot be used somehow.

If you are serious about this proposal, one way to move forwards is to make tool that converts kdbx <-> sqlite. If you can't roundtrip that conversion perfectly then the idea is dead on arrival.

The keepass ecosystem is comprised of a dozen implementations of the KDB(X) file spec. Some are better than others.

I built KeePass Tusk back in 2018, for example. This would kill the project and abandon 30K users without a rewrite of the JS engine (there are several now!)

I agree with you that KDBX sucks, but at this point a keepass based on SQLite would be keepass in name only, a new password manager to migrate to.

Some decent arguments for development concerns, but the users will certainly never notice.

For 10 years I've managed a family of 4 in a single KeePass db. Unique passwords across all accounts, random passwords instead of PII for "security questions", fake DOBs, and all other random security related stuff. Never had a single issue. Everything happens instantly as far as I can tell. And the file is 67kb.

My work dbs, separate only because they should be, are much smaller and simpler.

I love KeePass. Changing everything under the hood probably only has potential to make pain for the user. Best case is that nothing is made noticeably worse. Doesn't seem worth the risk.

Just checking the size of my .kdbx file: under 100K.

> My cursory (lol, get it?) understanding may be incorrect.

I don't get it. Is this a reference to database cursors? Or is it implying that the blog post was AI generated?

I don't think given the file size it is all that relevant.

I mean if I wanted to start new password manager right now it would be a good choice to "just use SQLite" but for existing solution backward compatibility is far more important

>Important to note is that every time a KDBX file is updated, no matter how small the edit was, the entire file gets rewritten.

This seems like an implementation issue rather than a format/spec issue.