phoerious

Then it's good that we're not doing manual memory management.

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.

There is actually very little we can do about local attackers, with or without AI. All we can do is mitigate.

Our entire development process is open on GitHub. You can see where we use or accept AI at any time.

The whole purpose RLVR alignment is to ensure objectively correct outputs.

I'm just an AI researcher, what do I know?

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.

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.

The extra functionality isn't opening security holes. It is central functionality that users have come to expect such as Auto-Type or support for YubiKeys. The Debian maintainer has decided to disable the WITH_XC_ALL flag, which disables ALL optional features (not sure why you consider this a lie).

Your claim that KeePassXC communicates with random webpages is also false. There are two cases in which websites are communicated with (none of them random): a) an optional update check (can be disabled), b) when you click the button to download a website's favicon. Please don't just state things that are not true.

I wouldn't say it's misleading or wrong. It's certainly a bit catchy, but it also aligns with a greater discussion that's going on at the moment. Regardless of the title, most people probably wouldn't or couldn't discuss scientific literature in-depth anyway, but search engine spam is something many can relate to, be it from Google or otherwise. It's certainly a topic we will be hearing about a lot more in the future. Besides, we didn't even anticipate this to be picked up by non-scientific journals that quickly, though the title may have helped. ;-)

Hi, I'm lead author of the study, so I can give some background on this. This is certainly valid criticism and we could have addressed our reasoning for using Startpage in more detail, but it just didn't fit in the paper anymore.

The reason we used Startpage is simply that it's much easier to scrape. We started off checking only Startpage (as proxy for Google) and DuckDuckGo (as proxy for Bing), since they are both simple to scrape and produce stable rankings. Plain Bing, on the other hand, is a lot trickier. You often get different results for the same query and you get blocked much more easily if you send too many. The only stable way to use Bing is via the (certainly not very cheap) API, though even that wouldn't necessarily guarantee the same user experience as the web frontend.

We did notice, however, that DDG (despite being mostly Bing) did deviate quite a bit in their results, so we started scraping Bing as well for a fairer comparison. As for Startpage, we did check it initially and we found the results to be virtually identical, except for a few minor rank differences here and there (which are probably just geo personalisation). The differences may have become larger now that Startpage also taps Bing to a certain amount, though when I do spot checks, the results are still sufficiently similar and they are also sufficiently different from what actual Bing gives you. Most prominently, Startpage/Google give you a lot more YouTube results, which we did another small spin-off study on (to be published at CHIIR this year https://downloads.webis.de/publications/papers/bevendorff_20...). Moreover, we could also measure certain immediate effects of Google's ranker updates in Startpage, which weren't as apparent in Bing. So we are confident that Startpage is a reasonable proxy for Google, though it's certainly something we will keep in mind for follow-up studies.

Funny you mention YouTube. We did another study on this as well. https://downloads.webis.de/publications/papers/bevendorff_20...

I clarified that on our website, since that topic comes up again and again: https://keepassxc.org/docs/#faq-general-plugins

Why do you want plugins? KeePassXC provides most of what KeePass needs plugins for out of the box in usually much better and more stable and tested quality. KeePassXC will never support plugins the way KeePass does and for good reason. Most plugins are unmaintained and some are outright dangerous to use. Your passwords are too precious to let unverified thirdparty plugins handle them.

If you need external functionality that is not available in KeePassXC, you can try to bolt it on via the KeePassXC-Browser API or open a feature request (or even better: pull request) to get it into the core application.

KeePassX was abandoned years ago, which is why KeePassXC exists. KeePass is a different product and more like the original inspiration for KeePassX/XC.

KeePassX has literally been abandoned, so you will not get updates of any kind: https://www.keepassx.org/index.html%3Fp=636.html

The problem isn't so much the language as the fact that it's very tedious if you only have access to the old Win32 API as a result of toolchain constraints. It is much easier with the VCpp toolchain.

Sounds like you should switch to KeePassXC if that's what you need.

Then it may excite you to see this: https://github.com/keepassxreboot/keepassxc/pull/6029

You guys should check out KeeShare in KeePassXC. :-)

We explicitly specified Menlo in the new release, because it is rather unambiguous (and monospace). I don't really understand your criticism.

(Full disclosure: I contribute to KeePassXC)

In fact, KeePassXC has shown to have better memory protection than KeePass: https://keepassxc.org/blog/2019-02-21-memory-security/ (note the article is from February, some things have changed since then, see below). The only thing we do not have at the moment is in-memory encryption. We do, however implement the following security measures on all platforms:

- prevent swapping of master key hashes (using gcry_malloc_secure)

- prevent non-root / admin access to our process memory (KeePass does NOT have this)

- overwrite all dynamically allocated memory with zeros on free

- disable any kind of coredump or crash reporting

A patch for in-memory encryption is being worked on, but needs further testing before it can be merged: https://github.com/keepassxreboot/keepassxc/pull/3055

Please note that this still cannot fully prevent swapping out of secrets. As soon as things are to be displayed somewhere in the GUI, they are basically out of our hands. We also cannot fully protect everything while the database is being loaded or written. However, the same applies to KeePass. There is just too much going on with memory management on modern operating systems.

I thought we settled on the PPA approach.

KeePassXC does support the KeePass2 format (i.e., KDBX3). It does not (yet) support the very latest format (KDBX4), but by default KeePass also still uses KDBX3, so both are compatible.

Would you be so kind to file a feature request for that on GitHub? Thanks!

Would you be so kind to file a feature request on GitHub? Here it gets lost. Thanks!

Just plug it in. ;-)

KDBX4 is a priority indeed, but we only have limited resources. We hoped to get it into 2.2.0, but it just wasn't possible. We really appreciate your patch and will make sure it lands in 2.3.0. It's not forgotten.