Code submissions either meet the standards of the project or they don't. Whether it was generated by human or AI is irrelevant.
It is extremely relevant. I refuse to touch it if it uses AI.
About KeePassXC's Code Quality Control
41–49 of 49 posts
Re: About KeePassXC's Code Quality Control
#42I 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…
I think a lot of folks end up copying their encrypted file to shared storage like Dropbox anyway. This doesn’t seem all that different from using 1pass.
Re: About KeePassXC's Code Quality Control
#43I 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…
I think a lot of folks end up copying their encrypted file to shared storage like Dropbox anyway. This doesn’t seem all that different from using 1pass.
I can see a few differences.
Pushing Keepass vault to cloud storage:
* No per-item synchronisation
* Full control over encryption of the database
* Choice of cloud storage to trust with vault
* Free as in beer if no using cloud (or using a free/already paid for offering)
1Password:
* Per-item sync and collaboration
* Full trust on the (closed-source) client apps over encryption of vault
* No choice of cloud
* No choice of encryption
* Mandatory paying subscription
Re: About KeePassXC's Code Quality Control
#44There'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.
> There's no way to determine whether a contributor used LLMs in part or full, not without them being honest about it.
Oh, you can tell.
Re: About KeePassXC's Code Quality Control
#45Code submissions either meet the standards of the project or they don't. Whether it was generated by human or AI is irrelevant.
It is extremely relevant. I refuse to touch it if it uses AI.
Yes absolutely relevant, especially in this software case. There is no requirement for mass-amounts of boilerplate code to be written here, just supposedly smart and correct cryptography and as little code as possible to do the job right... so if someone is using AI... that is a huge red flag.
An obvious sign that something is going horribly wrong in this project.
In fact i think this kind of news is enough to garner a huge influx of international hackers all targeting this package now, if they weren't already. They will be looking closely at the supply chain, phishing the hell out of the developers, physical intrusions where they can, its a hint that the developers might be stressed and making poor decisions, with huge payoff for infiltrating
Re: About KeePassXC's Code Quality Control
#46I 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…
Sorry but that is nonsense. "The file format is the basis for security, not the client application" is so wrong, any messing with the application is game over.
Hell if you leave your computer unlocked, a rubber-ducky could replace your executable and middleman your master password.
Re: About KeePassXC's Code Quality Control
#47I 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…
Sorry but that is nonsense. "The file format is the basis for security, not the client application" is so wrong, any messing with the application is game over. Hell if you leave your computer unlocked, a rubber-ducky could replace your executable and middleman your master password.
There is actually very little we can do about local attackers, with or without AI. All we can do is mitigate.
Re: About KeePassXC's Code Quality Control
#48Earlier quoted context omitted.
It is extremely relevant. I refuse to touch it if it uses AI.
Yes absolutely relevant, especially in this software case. There is no requirement for mass-amounts of boilerplate code to be written here, just supposedly smart and correct cryptography and as little code as possible to do the job right... so if someone is using AI... that is a huge red flag. An obvious sign that something is going horribly wrong in this project. In fact i think this kind of news is enough to garner…
Untrue. KeePassXC has large parts of UI boilerplate code and test cases. The cryptographic routines are the smallest part. They are pretty stable and don't change much. It's also not where we would be using AI.
Re: About KeePassXC's Code Quality Control
#49Code submissions either meet the standards of the project or they don't. Whether it was generated by human or AI is irrelevant.
>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 an…
Then it's good that we're not doing manual memory management.