Post by @dalias@hachyderm.io
So here’s the thing. My entire life is on Proton: email, calendar, documents, VPN, all my passwords, all my ID, all my important data.
My annual subscription is up at the end of January.
If they don’t oust Andy Yen by then, I’m out. The question is where?
Infomaniak seems to offer most of what Proton does but they also use AI.
What other options are there? I’m seeing people suggesting email alternatives. But I need a whole lot more than that.
@clacksee For passwords and 2FA, I've moved entirely to KeePass (KeePassXC on desktop, KeePassDX on mobile). It handles both passwords and TOTP codes, so I dropped Aegis. I run GrapheneOS on my phone, though it works just as well on stock Android. Vaults are synced locally between my PC and tablet — no cloud dependency. If I make changes while out, everything syncs back when I'm home. Fully local, fully in my control.
8 likes
@dalias Thanks for the heads-up, I wasn’t aware of this. I’m on Debian 13 and I installed KeePassXC from Flathub (2.8.0), not the Debian package (2.7.10). I’ll check what changed between the two and then decide what to do.
@dalias @enki_2931 @clacksee
@keepassxc
Are you sure about this? KeePass and KeePassXC are different applications.
@mlippert @enki_2931 @clacksee @keepassxc Oh maybe, I'm not sure. I can't even find an up-to-date KeePass source repo to check. I wasn't aware it was still a thing independent of KeePassXC and other forks.
@dalias @mlippert @enki_2931@mastodon.uno @clacksee @keepassxc Says who? Did you read the contribution policy?
@rakekniven @mlippert @clacksee @keepassxc Says their GitHub repo:
@dalias @rakekniven @clacksee @keepassxc I just did a quick scan of the last 2 years of commits and didn't see any commits by claude.
I do see some co-authored by copilot, but the other authors are people I believe would have carefully reviewed the code being committed. I could be wrong but at this point I don't agree about slop, and I still trust the integrity of the people developing keepassXC.
@dalias @rakekniven @clacksee @keepassxc ok, I guess we just disagree. Fair enough, everyone sets their own standards.
@mlippert @dalias @enki_2931 @clacksee @keepassxc Many of the KeePass apps are slopped, but the KeePass database format isn't
https://codeberg.org/ethical-foss/ai-free-foss-alternatives#local-password-managers
@varjolintu @enki_2931 @clacksee Are they actually valid and relevant to its threat model?
Most CVEs now are slop.
@varjolintu Since you didn't cite the CVE IDs I can't check what you're talking about, but CVE-2026-118673 looks like bs. AFAICT it's "user can exploit themselves".
This is exactly what I mean by slop CVEs. Bugs that are *of the form* of a vuln (memory corruption, UAF, etc.) but where there is not any (or at least not any significant) crossing of privilege domains that make it attack surface.
@dalias @varjolintu That's a pretty lazy / irresponsible approach to maintaining secure systems. You don't need an RCE to warrant a patch or CVE number. The fixed vulnerabilities are listed in the release blog post. https://keepassxc.org/blog/2026-10-21-2.8.0-released/
@phoerious @varjolintu No, for a "vulnerability" to be legitimate there needs to be a threat model for which it actually compromises the user's security, and this threat model needs to be one the developers intend to support.
"Any bug that corrupts memory, even if it's the user doing it to themselves, is a vuln" is not useful. It's how you end up swamping users with a feeling of hopelessness and push them to accept forced updates with forced malicious changes.
@dalias @phoerious @varjolintu The only threat model affected in this case is the same one that includes evil maid as a realistic attack, which is far out of the model the developers are addressing (and I don't think they make any pretense of it, either).
@varjolintu @phoerious I did. That's the basis on which I say they're not vulns. And they agree! To quote from your link:
"The CVEs are rated low to moderate severity. None of the vulnerabilities concern the security of KeePassXC’s core functionality or cryptography."
@dalias @phoerious I fixed two of those. First was a relatively easy way to get KeePassXC to crash from outside the application. Other one was returning *any* credentials just by using a crafted reference from a web page. So I fixed just some slop vuln reports and it's acceptable to leave another application open for these? Ok then.
@varjolintu @dalias A memory corruption is a memory corruption. Even if you believe it may not be immediately exploitable, it may become part of another exploit chain later. Thats why you fix them instead of ranting about “slop”. But ymmv.
@phoerious @varjolintu Yes bugs should be fixed. But they are not vulns and should not be misrepresented as such, and a project maintained by one very responsible person should not be maligned for not yet having fixed a minor, recently found bug that cannot be triggered unless you're actively trying to shoot yourself in the foot.
@dalias @phoerious If the vulnerability doesn't even require "shooting yourself in the foot" and attacker could get any credential from your database, I'd say that 's not just a "bug".
@varjolintu @phoerious I understand you're claiming there might be an attacker who exploited some browser vuln to attack the not-a-vuln bug in the password manager.
But if they already have code execution capability they can just attach a debugger to the password manager. Or perform any number of legitimate other ways to peek and poke at it without using the bug.
@dalias @phoerious The attacker is... me? This is pure nonsense. If you think these are only "bugs" and bugs should be fixed, then.. maybe that needs to be done, right?
The thing you just wrote confirms you did not read what those fixes did, and against what.
@varjolintu @phoerious Again you haven't cited the ones you want me to look at, so I'm going on the descriptions of the bugs in the only link you gave.