About KeePassXC's Code Quality Control

I feel like a lot of the comments here do not understand how KeePassXC actually works. It’s a client application that works with a standard encrypted file format. The file format is the basis for security, not the client application.

KeePassXC does not store any data. Nor does it receive connections from the Internet, like a server. Thus the risk is structurally lower than a commercial client-server application like LastPass or 1Password, which is actually in possession of your password data.

I use 1Password at work for its excellent collaboration features and good-enough security. For most people it replaces a post-it note or Excel file. It’s way better than those.

But for my passwords I use KeePass (the file format) and a variety of clients including KeePassXC. This statement about AI won’t change that, unless someone can give me a reason other than vague “AI bad” or “no vibe coding” like most comments so far.

Code submissions either meet the standards of the project or they don't. Whether it was generated by human or AI is irrelevant.

> We take no shortcuts. At KeePassXC, we use AI for

Followed by shortcuts

> As such, they are a net benefit and make KeePassXC strictly safer.

They can also waste author's/reviewer's time chasing imaginary ends, taking time away from the "regular" review, or with some level of trust add some plausibly explained vulnerability. Nothing is strict here

I'm sure if you ask your favorite AI bot, he'll come up with a few more reasons why the statement is overconfidently wrong.

Tell yourself what you want, but this sort of AI positive proclamation will make your project seem less trustworthy to many people.

I choose not to use a vibe coded password manager, rigorous review or not, to protect my entire digital existence, monetary assets and reputation.

It's the pinnacle of safety requirements, memory unsafe language, cryptography, incredibly high stakes.

I have the distinct displeasure having to review LLM output in pull requests and unfailingly they contain code the submitted doesn't fully understand.

There's no way to determine whether a contributor used LLMs in part or full, not without them being honest about it. With that in mind, this seems like a reasonable position. Been using KeePassXC since forever and will continue to do so. It might feel wrong to some, but these changes are inevitable and it's best to be prepared and become acquainted with that now rather than later.

I am now on the hunt for a non vibe coded alternative. I stopped open sourcing code after all my open code's licenses were broken by Microsoft and everyone else commercialising it. Which I guess is part of the point of why they did it and have put serious money to defending themselves in court against anyone that dare challenge it. Suffice to say I don't want anything to do with projects that participated in that theft and re-commercialisation of open source code.

Does not look like the original Keepass project is doing this which is the easiest migration away but I will check a bit deeper on their commits to be sure.

This just wrecked my trust in KeePassXC. Time to go see if anyone's going to continue this from a fork where they aren't setting themselves up for a massive security failure of some variety.

I'd trust them to know what they're with KeePassXC given their track record with it.

I didn't know about that and this is really concerning to me. AI has no place in security critical software like KeePassXC, and I remain unconvinced that they will only use it for simple tasks. I don't feel like I can trust this software any longer this is a password manager not just some random website where bugs basically don't matter. I hate that I have to replace yet another piece of software that I liked.

Y'know how there's "security theater"? https://en.wikipedia.org/wiki/Security_theater

I think there's an analogous subset: "llm-security theater".

There's so much pearl-clutching, pedantry, and noise from people who are obviously 1) not contributing to KeePassXC AND 2) never would contribute AND 3) are unaware of EXISTING bugs/issues/CVEs with KeePassXC. All they provide are vague abstract arguments from their own experience with LLMs, and they argue with the maintainers of KeyPassXC without giving specifics, as though they have the right to tell others how to run their repo when they're unable to link a single concrete problematic issue or PR.

Instead, all they have are "vibes", which is ironic.

> We take no shortcuts.

I mean... they are

isn't that the point? not as if "AI" leads to higher quality is it

> Certain more esoteric concerns about AI code being somehow inherently inferior to “real code” are not based in reality.

if this was true why the need to point out "we're not vibe coding", and create this process around it?

fork and move on

> we still code ourselves for work and for fun. This will not suddenly go away because we have another tool in our belts.

AI is just another way to write code. At the end of the day code is just text. It still needs to be reviewed - nothing about that is changing.

My great concern with regards to AI use is that it's easy to say "this will not impact how attentive I am", but... that's an assertion that one can't prove. It is very difficult to notice a slow-growing deficiency in attentiveness.

Now, is there hard evidence that AI use does lead to this in all cases? Not that I'm aware of. Just as there's no easy way to prove the difference between "I don't think this is impacting me, but it is" and "it really isn't".

It comes down to two unevidenced assertions - "this will reduce attentiveness" vs "no it won't". But I don't feel great about a project like this just going straight for "no it won't" as though that's something they feel with high confidence.

From where does that confidence come?