The KeePassXC kerfuffle
Please consider subscribing to LWN Subscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net.
KeePassXC is an open-source (GPLv3), cross-platform password manager with local-only data storage. The project comes with a number of build options that can be used to toggle optional features, such as browser integration and password database sharing. However, controversy ensued when Debian Developer Julian Klode decided to make use of these compile flags to disable these features to improve security in the keepassxc package uploaded to Debian unstable for the upcoming Debian 13 ("Trixie") release.
One of the selling points of KeePassXC, in the age of everything-as-a-service, is that it stores user passwords and secrets locally. It does have a few network features, such as downloading site favicons to display next to passwords for web services and for checking passwords against the "have I been pwned?" service. It also has interprocess communication (IPC) functionality to talk to browsers like Firefox, Chrome, and others that have KeePassXC browser extensions. The project provides build flags to turn these additional features off, if desired.
The idea of turning off optional features in KeePassXC's Debian package is not new, and Klode has gotten requests to do so as far back as 2020, though they had gone unanswered until now. A Debian user filed a bug report against KeePassXC in March 2020, asking for the program to be compiled without some of its optional features. Andreas Kloeckner disagreed, saying that he finds the features useful, and suggested creating a second package if users wanted a keepassxc package without those features. Another user, Tony Mancill, chimed in a year later saying he supported disabling networking. And then the bug sat for almost three years until April 2024, when the bug was closed after Klode uploaded the package with networking and IPC functionality turned off, along with a new keepassxc-full package with the original functionality. This meant that the new package no longer supported any features, like browser integration or password sharing, that depended on networking or communicating with processes like Firefox or USB input from hardware tokens.
XZ-inspired
Why did Klode decide to take action on this bug several years after the fact? In an email response to questions, Klode wrote that the XZ backdoor spurred on the change. It made him "more concerned about building optional code into the default package". He suggested that optional features were more likely to contain vulnerabilities than the core application, because those features may only be reviewed by a single maintainer. It is easier, he said, for vulnerabilities to creep in if features have fewer reviewers.
The minimal build, he said, was well-aligned with what typical Debian users would want. Debian is well-known for stripping out features to improve security and privacy, and these users had chosen a password manager that stores its data locally "because they don't trust sharing their files with other users". Klode said that he did not think there would be much overlap between "these paranoid users" and users who wanted network access and to allow other applications to interact with the password database. "Certainly I've only ever used the clipboard for it and none of these features."
Users hit snags
Klode may not use the disabled features, but others do. Michael Musenbrock filed a bug report against the new package almost immediately after it was uploaded to Debian unstable, and reported that he was unable to open his password database without hardware-key support. He endorsed the idea of splitting the package up so the default package would be a " real network-less password manager ", but suggested restoring the hardware-key functionality.
On May 6, Hernán Cabañas commented on the same bug report, after he had asked the upstream about missing browser-integration functionality. Jonathan White, a member of the KeePassXC project team, said that removing the functionality was a terrible decision, and recommended complaining to Debian. " They should have made a keepassxc-min instead. "
On May 10, Cedric Schmeits opened an issue on the KeePassXC GitHub repository, complaining that browser integration had stopped working with KeePassXC version 2.7.7, and most of the application's options had disappeared from its settings. White tagged Klode and said that the change " needs to be reverted asap ". He later edited the comment to add that Schmeits's bug report was the fourth that the project had received about the package change, and demanded: " Put the base package back where it was and create a keepassxc-minimal. "
Klode replied that was not going to happen. It was a mistake to ship with these plugins enabled, and " our responsibility to our users to provide them with the most secure option possible as the default ". He acknowledged that it would be painful for a while, " as users annoyingly do not read the NEWS files they should be reading ", and went on to say that the disabled features didn't belong in a local password manager anyway. But, if users needed them, they could " install the crappy version but obviously this increases the risk of drive-by contributor attacks ". To that, White responded: " Good luck to you. Really bad decision. We will be sure to let everyone know. " That day, the KeePassXC project posted a notice on Fosstodon that Debian users should " be aware " that " the maintainer of the KeePassXC package for Debian has unilaterally decided to remove ALL features from it ". This escalated things quickly, as the Fosstodon post made the front page of Lobste.rs and Hacker News.
White made it clear that the intention was to put Klode's feet to the virtual fire:
Would have been nice to have [a discussion] about a month ago when this was unilaterally put into action. Alas, here we are. So yah flaming arrows will absolutely be thrown because there was no chance at proper discourse. This thread should be a lesson to downstream folks who think they know what's "best" for the user.
That seems to have succeeded in directing angry users at Klode. In his email to LWN, he acknowledged that some of his wording was unfortunate, but said that he was in a hurry and wanted to provide a response before traveling. The hasty reply ended up sparking a disproportionate backlash: " I don't think it's healthy for people being subjected to a hate mob on multiple channels for several days like this. "
Klode's comments did more to inflame upstream (and a number of users and onlookers) than inform, and they responded in kind. That is unfortunate: objectively speaking, a legitimate case can be made for adhering to the upstream's default configuration, or for the packager to exercise their best judgment in the configuration that is best suited to the distribution's users. Neither is correct, neither is wrong, it's a matter of perspective and opinion.
For example, former KeePassXC team member Davide Silvetti, initially agreed with the decision to offer a package with additional options turned off as the default. He said that the option to compile without plugins was added in 2016 to reduce the attack surface and potential vulnerabilities. He suggested that the project add a message in place of the usual browser integration feature tab that that suggests the user install the "full" version if they want that capability.
That did not appeal to Janek Bevendorff, a current member of the project team. " If anything, we will reduce the number of such compile-time flags in the future, so these things cannot be disabled anymore. " The safest version of the program, he said, " is not the one with all flags disabled, but the one which is tested best by us and by the majority of our users ".
Silvetti disagreed and asserted that disabling compile-time flags for additional features " actually removes code and reduce[s] attack surface ", making the final version more secure. He also noted that package maintainers for the Linux distributions " (contrary to KeePassXC maintainers) have actual telemetry data and crash reports affecting the end users ". That said, he then wrote that it would be better to continue with the keepassxc package with all features enabled, and offer the minimal version as keepassxc-minimal .
Much ado about...
For all the turmoil over the change, the only users who are actually at risk of a surprise change to the keepassxc package are those running testing or unstable releases. In response to a question about whether it is really reasonable to expect that users read NEWS files, Klode wrote that users of Debian unstable or testing are not average Linux users, but "people who have chosen to test the next Debian release in a rolling development state". Those users should have apt-listchanges installed "which will print these critical news items before the upgrades are installed".
The actual impact will be negligible for users of stable versions of Debian, Ubuntu, and other Debian-derived distributions. Klode said that when Debian Trixie is released, upgrades and new installs of the keepassxc package will receive a transitional package that prompts them to decide between "full" and "minimal" packages. Klode says that this will allow users upgrading from bookworm to preserve their current setup. Future releases will have a "virtual" keepassxc package that, again, requires the user to explicitly select one or the other.
Even if one takes the position that Klode is completely wrong in his rationale for and handling of this change, the real impact is minor. One of the things we should have learned from the XZ backdoor episode is that no one benefits from making participation in open-source development and distribution more unpleasant and stressful. Maintainers should be able to screw up in public without fear of an internet pile-on.