[HN Gopher] About KeePassXC's Code Quality Control
___________________________________________________________________
About KeePassXC's Code Quality Control
Author : haakon
Score : 94 points
Date : 2025-11-09 14:44 UTC (8 hours ago)
(HTM) web link (keepassxc.org)
(TXT) w3m dump (keepassxc.org)
| blibble wrote:
| > 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
| droidmonkey wrote:
| We did not create this process for AI, it has been our process
| since 2016.
| jpeterson wrote:
| Code submissions either meet the standards of the project or they
| don't. Whether it was generated by human or AI is irrelevant.
| KronisLV wrote:
| > Whether it was generated by human or AI is irrelevant.
|
| No, some projects take fundamental issues with AI, be it
| ethical, copyright related, or raising doubts over whether
| people even understand the code they're submitting and whether
| it'll be maintainable long term or even work.
|
| There was some drama around that with GZDoom:
| https://arstechnica.com/gaming/2025/10/civil-war-gzdoom-fan-...
| (although that was a particular messy case where the code broke
| things because the dev couldn't even test it and also straight
| up merged it; so probably governance problems in the project as
| well)
|
| But the bottom line is that some projects will disallow AI on a
| principled basis and they don't care just about the quality of
| the code, rather that it was written by an actual person.
| Whether it's possible to just not care about that and sneak
| stuff in regardless (e.g. using autocomplete and so on, maybe
| vibe coding a prototype and then making it your own to _some
| degree_ ), or whether it's possible to use it as any other tool
| in development, that's another story.
|
| Edit: to clarify my personal stance, I'm largely in the "code
| is code" camp - either it meets some standard, or it doesn't.
| It's a bit like with art - whether you prefer something with
| soul or mindless slop, unfortunately for some the reckoning is
| that the purse holders often really do not care.
| arghwhat wrote:
| > No, some projects take fundamental issues with AI, be it
| ethical, copyright related, or raising doubts over whether
| people even understand the code they're submitting and
| whether it'll be maintainable long term or even work.
|
| These issues are no different for normal submissions.
|
| You are responsible for taking ownership and having sorted
| out copyright. You may accidentally through prior knowledge
| write something identical to pre-existing code with pre-
| existing copyright. Or steal it straight off StackOverflow.
| Same for an LLM - at least Github Copilot has a feature to
| detect literal duplicates.
|
| You are responsible for ensuring the code you submit makes
| sense and is maintainable, and the reviewer will question
| this. Many submit hand-written, unmaintainable garbage. This
| is not an LLM specific issue.
|
| Ethics is another thing, but I don't agree with any proposed
| issues. Learning from the works of others is an extremely
| human thing, and I don't see a problem being created by the
| fact that the experience was contained in an intermediate
| box.
|
| The real problem is that there are a lot of extremely lazy
| individuals thinking that they are now developers because
| they can make ChatGPT/Claude write them a PR, and throw a
| tantrum over how it's discriminating against them to disallow
| the work on the basis that they don't understand it.
|
| That is: The problem is _people_ , as it always has been. Not
| LLMs.
| riedel wrote:
| I would agree, IMHO keepassXC should however actually lay out
| their review standards better to actually be able to review
| security relevant code. I am a happy keepassxc user on multiple
| devices. However, trying to use and extend it in various
| settings, I simply still do not understand their complete
| threat model, which makes it very difficult to understand the
| impact of many of extensions it provides: being it for quick
| unlocking or API connection to browsers that can be used for
| arbitrary clients.
| s_ting765 wrote:
| People get confused talking about AI. For some reason they skip
| the fact that a human prompted the LLM for the generated
| output. One could almost think AI is an agent all on its own.
| Barrin92 wrote:
| >Whether it was generated by human or AI is irrelevant.
|
| No. These systems are still so mindboggingly bad at anything
| that involves manual memory management and pointers that even
| entertaining the idea of using them for something as critical
| as a non-trivial large c++ codebase, for a password manager no
| less, is nuts. It displays a lack of concern for security and
| propensity for shortcuts that I don't want to touch anything by
| people who even remotely consider this appropriate.
| thunderfork wrote:
| 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?
| droidmonkey wrote:
| > From where does that confidence come?
|
| From decades of experience, quite honestly.
| eviks wrote:
| How can you have decades of experience in a technology less
| than a single decade old? Sounds like ones of those HR
| minimum requirement memes
| droidmonkey wrote:
| Decades of programming and open source experience.
| blibble wrote:
| you have decades of experience of reviewing code produced at
| industrial scale to look plausible, but with zero underlying
| understanding, mental model or any reference to ground truth?
|
| glad I don't work where you do!
|
| it's actually even worse than that: the learning process to
| produce it doesn't care about correctness at all, not even
| slightly
|
| the only thing that matters is producing plausible enough
| looking output to con the human into pressing "accept"
|
| (can you see why people would be upset about feeding output
| generated by this process into a security critical piece of
| software?)
| phoerious wrote:
| The statement that correctness plays no role in the
| training process is objectively false. It's untrue for text
| LLMs, even more so for code LLMs. Correct would be that the
| training process and the architecture of LLMs cannot
| guarantee correctness.
| blibble wrote:
| > The statement that correctness plays no role in the
| training process is objectively false.
|
| this statement is objectively false.
| phoerious wrote:
| I'm just an AI researcher, what do I know?
| blibble wrote:
| > I'm just an AI researcher, what do I know?
|
| me too! what do I know?
|
| (at least now we know where the push for this dreadful
| policy is coming from)
| phoerious wrote:
| The whole purpose RLVR alignment is to ensure objectively
| correct outputs.
| eviks wrote:
| > 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.
| phoerious wrote:
| If we're wasting anyone's time, it's our own. Your comment
| reads like the AI would make up hundreds of invalid complaints,
| which is simply not true. You can see for yourself in our
| GitHub repository if you care.
| Firehawke wrote:
| 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.
| PaulKeeble wrote:
| 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.
| AlexErrant wrote:
| The original Keepass project has 11 CVEs. XC has 3, and has
| disputed all of them with e.g. "the vendor disputes this
| because memory-management constraints make this unavoidable in
| the current design and other realistic designs", etc.
| droidmonkey wrote:
| Additionally, the original KeePass project has no public
| development or public review process for their code. They do
| everything behind the scenes and only publish code when a
| release is made. KeePass is "code available" open source.
| Lariscus wrote:
| 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.
| phoerious wrote:
| Our entire development process is open on GitHub. You can see
| where we use or accept AI at any time.
| Lariscus wrote:
| That's all nice but I still don't want slop code in an
| application as security critical as a password manager. The
| correct percentage of slop code for a password manager is 0%
| and it's pants on head crazy to claim otherwise.
|
| I have dug around a bit and found a thread mastodon thread
| that doesn't inspire confidence[1]. KeePassXC seems
| completely untrustworthy at this point not only have they
| jumped on the AI bandwagon, they also seemingly don't know
| what a zero-day is. I genuinely liked KeePassXC and used it
| for years now I am spending my Sunday evening researching
| alternatives.
|
| [1] https://fosstodon.org/@2something@transfem.social/1148367
| 097...
| irilesscent wrote:
| I'd trust them to know what they're with KeePassXC given their
| track record with it.
| ysleepy wrote:
| 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.
| AlexErrant wrote:
| 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.
| 0x_rs wrote:
| 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.
| cadamsdotcom wrote:
| > 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.
___________________________________________________________________
(page generated 2025-11-09 23:02 UTC)