71–80 of 105 posts
The best UX improvement in this release (IMHO) is pretty buried in the changelog, and I don't see it mentioned here: no more lock files! If you use Keepass on something like Dropbox it's a blessing.
Anybody have thoughts about where to store the encrypted database for backup? Would it be foolish to keep the database somewhere publicly accessible?
You either need to remember the password for the online backup service, or you need to have another copy of the file in a remote location that you can access physically, like on your work PC if you don't work from home, or at a family/friend's.
Serious question: why should I leave KeePassX ?
Q: Why KeePassXC instead of KeePassX?
A: KeePassX is an amazing password manager, but hasn't seen much active development for quite a while. Many good pull requests were never merged and the original project is missing some features which users can expect from a modern password manager. Hence, we decided to fork KeePassX to continue its development and provide you with everything you love about KeePassX plus many new features and bugfixes.The best UX improvement in this release (IMHO) is pretty buried in the changelog, and I don't see it mentioned here: no more lock files! If you use Keepass on something like Dropbox it's a blessing.
> I was going to add tests for "concurrent" access of the same file in phase 2 of these changes. Phase 2 is refactoring the saving process entirely to make it asynchronous and robust to file sync services.
I was a longtime user of KeePassX. The UI was terrible, but it was free, open source and most importantly cross platform. After KeePass2 made the DB incompatible and rewrote everything in C# it stopped being a proper cross platform product and I investigated aternatices. I've since moved to enpass and I'm very happy. Enpass is a great, native app on Win/Mac/Linux and has native Android/iOS apps (with fingerprint supp…
Probably you mean KeePass (the "original" one), which is written in C# and requires Mono in Linux ? KeepassX has always been native C++ and cross-platform.
Previous thread about KeepPassXC 2.2.0: https://news.ycombinator.com/item?id=14633576 I used KeePassXC for a period, but from these release notes, the UI/UX still isn't great. If you're on macOS, I recommend MacPass, which feels more native to the system, is compatible with existing KBDX databases and most-importantly, is also open-source: https://github.com/MacPass/MacPass
I just switched from MacPass to KeePassXC for the reason mentioned in release notes: it obsoletes the HTTP Connector and uses another mechanism. MacPass keeps using HTTP, and it is uknown, when it will do the same switch. Given that I use multiple computers, and the extensions are synced, I want to use the same mechanism on all of them.
It really looks like AppImage is taking the lead among these new packaging technologies. When the project does provide these sorts of packages you always see AppImages, but rarely see Snap or Flatpak based images.
Earlier quoted context omitted.
What are the advantages/disadvantages of using Argon2/ChaCha20 over the current AES implementation? What are good parameters for those algos?
Well, in my amateurish opinion - there was nothing wrong with the existing AES encryption implementation. But they also had a key derivation function based on running many iterations of AES, which was weird and non-standard, I mean it seemed like it would work, but it's not proven in the cryptographic community. Now they've switched to Argon2 which is a very well reviewed KDF and I have a lot more faith in that. Code…