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.
