I've glanced over the article - I think using SQLCypher makes sense if it benefits Keepass project internally, meaning makes it easier to implement new features or fix bugs.
I do not see how it would benefits end users in any significant way. Sure, you can look inside the database, how many people need that?
Dumping the database to CSV is not a good backup, schema changes over time, what was dumped from one version of the app would not work for importing into another version if schema changes. Backup it needs a versioned schema format, which would actually look like KDBX format if implemented in XML :-)
I'm working on an alternative to KeePass/KeepassXC called Lockstep - it is local-first password manager that supports sync natively.
It uses SQLCypher as local data store and keeps KeePass-compatible data model - supports import of .kdbx database.
SQLCypher and different schema used in Lockstep alone did not solve any problems that I have with Keepass. Those problems are sync and sharing.
Solving sync and sharing cannot be done on whole database file level, as it implemented now in KeePass. Changes need to be tracked at the password record level, all changes need to persisted as operations log and that log needs to be distributed across devices.
The above means writing a whole protocol, and that's a lot more work than changing local storage.
I'd say it's mainly to do with browser/iOS plugins not being responsive. I find myself often resorting to opening the app and copying and pasting the password or other info because autofill function doesn't work on different websites.
Otherwise minor UI things like categories on the sidebar which made it easy to navigate, but they got rid of it a while back.
Sync requires a server, however server does not see any secret data, it is only used to relay encrypted hash-chained ops log between devices. It's intended to be self-hosting friendly - server is single binary backed by SQLite.
It's project is early-alfa, CLI app, Keepass import and sever/sync work for the most part, there is MacOS app in progress and plans for a iOS app and a browser extension.
Not ready for production and it's not audited.
I'm currently using KeepassXC/Keepasium with Syncting, but I want a better solution - something that supports trouble-free sync natively and allows me to own the system
I do not want to self host either, for exactly the same reasons.
However, I do want to have full control of my secret data beyond the secrets themselves, ideally w/out self hosting, i.e. I want to have crypto-proven control over whom I'm sharing secrets with, I want to have have cryto-level assurance that the service cannot use recovery/escrow mechanism to unlock my secrets data stored on the cloud w/out my consent.
Apple Passwords comes closest to what I want, but it's not cross platform.
I'm going to follow your project, it looks good. It's "alpha" btw. I wouldn't usually correct but as you're posting about something you want people to look at you might be interested in a correction.
Working on MacOS app that detects an active meeting in one of the commonly used apps and then turns on a LED "presence" light. The purpose to let others know that you are "on air" at this moment.
Current release candidate supports detecting Teams Meeting and Slack Huddle.
I do not see how it would benefits end users in any significant way. Sure, you can look inside the database, how many people need that?
Dumping the database to CSV is not a good backup, schema changes over time, what was dumped from one version of the app would not work for importing into another version if schema changes. Backup it needs a versioned schema format, which would actually look like KDBX format if implemented in XML :-)
reply