With cases like these, is it possible for you to simply copy the important text data into a note, or do you absolutely need the full pdf? Most attachments can be reduced down to their barest text form to avoid bloating the db.
Jason Donenfield is just a juggernaut. From WireGuard (and the client apps on every platform!) to passwordstore to cgit. This guy is insane. I’ve also always loved the look of cgit. Reminds me a lot of the Fossil VCS web interface in some ways.
Exactly. As such, people in the thread with huge dbs have a poor UX when they really do not need to. Also, people who have experienced corruption issues on network storage due to the default saving method (I personally have never experienced this).
Of course, the technical backbone of a product is rarely a user concern. But, changing the store allows for new design decisions when making the schema that are not tied to the old (IMO) technical debt of the KDBX format.
Users have wanted proper custom entry templates for years in order to input their card details into the manager. BitWarden, CodeBook, and others all have this built in without needing to fiddle with attributes and autofill to make it work.
I think a major change like this is worth it when we consider the KeePass of the next decade or two. This is genuinely my most important file by a longshot. Basing it on SQLite is just the right move for future proofing.
> The migration process would also be frictionless for users, it is a simple data map between probably the two easiest formats of all time.
I cannot imagine how you could mess this up. The developers already implement numerous export formats. The migration is the easiest part. The actual implementation of a new data format into the codebase and all the new security and robustness testing is the difficult part.
KDBX seems unique in this threat model out of the major providers. The cloud ones all use a relational DB, while major local ones like Enpass & Codebook just use a SQLCipher store. I wish someone with some real experience here would chime in: What metadata does a SQLCipher DB leak that a KDBX file does not? I mention that both of them obviously reveal the size of your vault to an attacker (w/ KDBX reporting the size more accurately, ultimately irrelevant), which is pragmatically unavoidable information leakage.
You lose the convenience of one file though. In this case you might as well use a purpose built encryption tool rather than force KeePass into this usecase. A VeraCrypt container or encrypted overlay filesystem are a significant performance and UX upgrade since you are already willing to concede managing one file.
That's true regarding the one file convenience but from another angle it's a separation of concerns, especially considering it's a pdf accessed very occasionally.
I maybe half agree with you about the encrypted overlay filesystem but only in respect to files, not passwords though. I tend not to keep files in KP, if I need a singular encrypted file I'd probably 7zip it (7z format) with a password and encrypt the filenames. The password goes in KP as does the location.
Yes we agree. Keep the passwords in the password manager and keep the files in the EOFS. If you need true seperation between those files, just make different containers or FS for them.
Really? To me that app is like the WeChat of banking. It just does so many things. Do not even get my started on the non-standard long totp that they force you to enter when trying to navigate certain parts of the app (you're already authed, why reauth?!).
I think the Schwab app-for doing as many things as the Chase app, is a much smoother experience.
A commenter here recently just asked me if I have considered BitWarden due to my gripes with KeePass. KeePass cannot rent-seek off my passwords. You can of course host BitWarden, but the official software can always get worse (see Minio). Thankfully we have community run versions of the BitWarden server (VaultWarden), whereas 1password customers are left to dry. There just isn't any money in personal password managers, and restricting features like TOTP (BitWarden free tier) rarely entices the average person to get a paid plan.
This is a reductionist take on what password managers actually need to do. A journal log is actually worse than the XML in this regard in that the number of events far exceeds the actual relevant relations. Also, adding an attachment/icon his no longer possible. Simple group associations and tags also become a complex nightmare in a log based system, whereas in SQLite they are super easy relationships. Relating passkeys, totp strings, icons, extensive history, etc all to one entry becomes too much of a task for that kind of format to handle.
It's actually very simple to read a journal to determine the full current state of the database. It's potentially even faster than parsing XML, yielding exactly the same in-memory structure. Your computer will do it faster than you can cancel the operation. This also gives you history for free, rather than as nested entries (though you might have to write a log flattener to prune old journal entries). The operations required to parse log entries like "icon 4 is now this data" and "entry 791 now uses icon 4" are minuscule. There is no complexity, no nightmare, no loss of relations.
I am not advocating for KeePass switching to a journal, however, because the current ecosystem is fine.
reply