KeePassXC, an open-source password manager renowned for its robust security features and cross-platform compatibility, has recently been spotlighted. Here’s what it’s all about.
A few days ago, an Ubuntu user noted that the browser integration feature for KeePassXC had vanished, rendering the corresponding browser extension non-functional. As you can guess, this feature is essential, as it significantly justifies using such password managers.
A follow-up check by a member of the KeePassXC team revealed that the Debian developer had removed some functionalities from the application. When he requested that the original functionalities be restored, Julian Klode, Debian Developer and Ubuntu Core Developer answered:
“I’m afraid that’s not going to happen. It was a mistake to ship with all plugins built by default. This will be painful for a year as users annoyingly do not read the NEWS files they should be reading but there’s little that can be done about that.
It is our responsibility to our users to provide them the most secure option possible as the default. All of these features are superfluous and do not really belong in a local password database manager, these developments are all utterly misguided.
Users who need this crap can install the crappy version but obviously this increases the risk of drive-by contributor attacks.”
I’m going to put it this way and hope to be understood. This type of response and attitude shown here perfectly aligns with the “Ubuntu Core Developer” profile, where users often have no choice but to accept the imposed views on how things should work and what tools to use.
However, this approach is difficult to reconcile with the “Debian Developer” part, given Debian’s reputation as one of the most democratic Linux distributions, where such a stance is not typically anticipated.
What led to this change? According to Klode, the current KeePassXC app, with all its functionalities, presents a broader attack surface.
I wouldn’t venture to say if this is true, but if we follow this approach, wouldn’t we find ourselves in a situation with hundreds or even thousands more applications subject to feature cuts?
What about systemd, for example? Doesn’t it represent an enormous potential attack surface? Let’s cut some features just because of a personal disagreement on how it’s built.
So, imposing views and solutions may be a Canonical-way, but it’s certainly not a Debian-way. No prior discussion. Just someone deciding and cutting features. As the KeePassXC developer mentions:
“No, this was not communicated to us before hand, nor was there a chance to collaborate on an effective solution for both parties. All I can say is, use Flatpak and get away from distro lock in altogether.”
In addition, as a user participating in the discussion noted, pointing to this link for reference:
“It is generally a violation of Debian policy for an upgrade to break existing functionality it is also generally encouraged to provide builds that allow for choice and self determination for system’s operators.”
Additionally, the KeePassXC developers highlight that user complaints are now directed to them rather than the responsible Debian developer. Moreover, as a longstanding open-source project, such actions can negatively impact the project’s reputation.
Who it affects: Users of the stable versions of Ubuntu and Debian still have access to the full-featured version of KeePassXC. However, those betting on Debian Testing will encounter the following:
Instead of this:
So, what is the current solution? A fully functional KeePassXC package containing all features, dubbed “keepassxc-full,” is now available in Debian’s testing and unstable repositories.
In conclusion, all this prompts important questions regardless of who is right or wrong in this situation. Notably, is this an isolated case, or should users anticipate similar instances where a single perspective dictates software usage? I am confident that it will not come to that. After all, who needs Debuntu?
You can find the complete discussion of the case here.
Hence the advantage of distributions like Archlinux where the policy is not to make changes to software. Deal only with upstream and use it as is, then clearly document on installation your further options should you want them.
I think, we should not call him a Debian developer (ahem, maintainer?), it’s an Ubuntu’s (or in general commercial) attitude. Not doing the right thing but get things done, even if they are wrong. That’s exactly why I use Debian. Such things are usually solved before it hits the users (though, I am on the testing and unstable branches, so I will be part of the discussion). Well, I understand that on Arch you are more independent. But I guess as Arch user you have to solve many inconsistencies by yourself that are usually managed by Debian maintainers. E.g. I like all these /etc/xxx.d where packages can drop their own files mostly independently. And the unstable/testing/stable cycle. If something does not work just go back to the stable version (though everyone says, mixing is not the way to go, I always used it like that and it works well for me, just some more manual dependency resolution from time to time).
It is more than some of KeePassXC’s network functionality. It includes Yubikey support and autotype. But if this is about security, then how is removing the browser integration more secure? As doing so promotes storing passwords in the clipboard(s), stops the anti phising functionlity and removes passkeys….
“But the plans were on display…” “On display? I eventually had to go down to the cellar to find them.” “That’s the display department.” “With a flashlight.” “Ah, well, the lights had probably gone.” “So had the stairs.” “But look, you found the notice, didn’t you?” “Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”
―Douglas Adams,The Hitchhiker’s Guide to the Galaxy
I run Debian stable and use KeePassXC. I can understand that this might be an area of discussion, but the response from the Debian Developer sucks.
I don’t run software that denies my agency. If this is Debian’s new approach, I will look to distro hop in the future.
“… I will look to distro hop in the future. “
Please visit and evaluate the BSD systems.
“All I can say is, use Flatpak and get away from distro lock in altogether.”
But I thought the browser plugin didn’t work at all with flatpak, or snap, because of their sandboxing and permissions? Last time I tried, it didn’t work. I was then told that it wasn’t possible for the applications to communicate with each other if either of them (the browser or keepassxc) was in a sandbox environment.
If that’s [still?] true, then that rules out Flatpak or snap as solutions to problems like this.
I use KeepassXC in flatpak format, it works with browsers shipped by distro repos. Sadly, flatpak KeePassXC cannot interact with flatpak browser.
can’t this be solved using flatseal to allow some more rights if necessary? (in case you are not using that flatpak browser to isolate it)
I can understand the reasoning. I cannot understand the level of arrogance in the response. Is this man some Linus wannabe?
I like Debian. It was the first distro I used, but with things like these I’m glad I went Arch (btw) so I can get vanilla software straight from their devs.
“use Flatpak and get away from distro lock in altogether.”
Got that right! I’m on openSUSE Tumbleweed, a rolling release, and I’ve learned through sad experience that any app that is not directly supported – or is improperly supported as in the case of Ubuntu KeePassXC – is best installed through an AppImage, a Flatpak, or (shudder) a snap. Otherwise it will be messed up at some point during an update.