In this case, there does seem to be reasonable security justifications for it, and an alternative is provided.
It's KeePassXC's job to secure the software and produce features that fulfill users' needs as they see fit. Julian's role as maintainer may intersect with that to a limited extent, in deciding on what kind of defaults best fit the rest of the OS. But, in this case, the developers of the software disagree with his justifications, and reasonable users are also disagreeing with the change.
It seems clear Julian wandered outside his role a bit here.
Is KeepassXC even a company ? looking at their site and wikipedia, they're just a bunch of people dedicated enough to maintain the project. Looking at the donation page [0] they don't even list anything going to themselves in the use of the money.
So they're effectively paying with their time to keep the thing alive. If anything the community seem to own a ton to these guys.
The best part of free software is it sometimes produces stuff you never would have been willing to pay to develop (Linux), and sometimes at quality levels too high to be rational for the market to provide (sqlite).
The worst part of free software is you get what you get, and the developers don't have to listen to you. (And as a developer, the gift recipients aren't always so grateful either.)
I do a lot of volunteer work too. Guess what? My decisions in those roles are not unimpeachable. Being a volunteer also does not mean you are owed anything, even gratitude. It's a thing you choose to do, and if you don't like doing it anymore, then you should stop doing it.
Package maintainers aren't self-sacrificial saints or all that unique as volunteers go.
This is a bad decision. It deserves criticism and discussion. The volunteer status of package maintainership is irrelevant.
By putting something out into the world you're creating connections with others. If people like what you've built and start to rely on it then that puts power into your hands, and any time you have power over others it should be wielded responsibly.
Volunteering doesn't give people a pass to screw over others.
I bet that if a bug is found in the connection API and passwords leak, we would impale the head of the mantainer in a pike for not defaulting to safe mode, or to have connection at all.
> Package maintainers aren't self-sacrificial saints or all that unique as volunteers go.
If you want keepassx, you can go install it. If you want the Debian archive's version, install that. All the options are open to critique, but the average Debian maintainer is doing so much more good than the occasional bad decision that they get a lot of benefit-of-doubt on this sort of choice. And some reasonable expectations of respect.
The functions related to Internet are:
- getting the favicon for a specific entry (needs to be ran manually with an option to download via a DuckDuckGo proxy)
- checking entries against HIBP (needs to be done manually in a submenu with a giant notice)
Also this is about KeePassXC not KeePass which is a completely different project. There is also KeePassX, KeePassDX, KeeWeb, KeePass-electron and so on and so forth.
I think that expectation ends once you start calling the other party's software "crappy".
Disagree. I use KeePassXC because I would prefer to have my passwords on my computer, instead of somebody else's computer (and I am willing to accept responsibility for managing my own password file).
That is a delineation that is parallel to, but not the same as, "don't connect to the internet". Browser integration is a required feature for a modern password manager; without it, you don't have a password manager, you have an encrypted notepad. HIBP integration is, likewise, net-good for users.
Also, as the KeePassXC devs have repeatedly pointed out in multiple places, these features are compiled in, but not enabled by default. Users who do not wish to use them can simply ignore them. Julian's argument at best seems to be some kind of concern about software supply chain; he is compiling the package without these features so that they are no longer available to the users who do want them.
The people making the arguments in favor of this change "for security reasons" aren't even making strong arguments for it.
> If you want keepassx, you can go install it...
Okay. And if you want a super-paranoid version of KeePassXC without these features compiled in, you can... go compile it that way.
Like everyone else, I already have thousands of little time sinks to contend with simultaneous to other increasing pressures in life. I am investing some time now to try to prevent another bad decision from adding to those faffs.
> some reasonable expectations of respect.
First, from my reading here and on the Mastodon thread and on the GitHub thread, most people have expressed dissatisfaction with this decision without crossing the line into disrespect towards the maintainer. The KeePassXC devs have maybe gotten a little heated, but they deserve all the same allowances you'd give to a package maintainer. They are getting bug reports due to downstream's decision, which they strongly disagree with. That sucks. There is a little bit of the usual internet noise, but otherwise, this is about the best discourse that could be expected for something like this.
Second, Julian himself kinda invited a strong negative response when he replied early on with, "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. ... 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..."
---
Getting back to some substantive discussion, it seems unlikely Julian is going to change his mind on this. This seems like a clear failure of package stewardship to me; KeePassXC's best move IMO is to set up their own repository and provide instructions for adding their repo and key to apt and then pin their keepassxc package. It's a bit of a nuisance for them, but probably less headache than ongoing bug reports and noise from the internet. There's already a lot of other software that gets installed this way, so I think it's fair to expect the average Debian user to be able to handle this process -- it's copy-and-pasting about four lines into your terminal. Then, Julian will no longer need to bear the burden of maintaining the package.
Not really? I've been using KeePassXC without a browser extension for a while, probably not years but certainly many months. That doesn't make it any less of a password manager - it lets me generate random strings to use for each account, keeps them safe and encrypted, and also lets me enable TOTP for an unlimited number of accounts. That's pretty much a password manager to me (TOTP is extra but much appreciated).
It's absolutely reasonable to say "Browser integration is a required feature for a modern password manager".
Volunteers by definition do not (or at least should not) expect anything in return for their time. If you want respect as a so-called volunteer, you're not a volunteer.
I've seen both good and bad package maintainers, too.
That isn't really true. For starters, paid volunteers are actually a thing that happens from time to time. Secondly; there would be no volunteers if they didn't get something for their time. It is just generally that something isn't money. Volunteers aren't expected to be selfless.
Am I a volunteer?
You are technically incorrect. The US army, for example, is manned more or less entirely with paid volunteers.
And while many volunteers may not get formal compensation, they have to expect to get something out of the experience. Otherwise they would not do it. The subset of volunteers who are in it purely for a biblically pure sense of charity is tiny. And there is no expectation that Debian developers are motivated by some cultish wish to do good for the sake of free software. They're allowed to be motivated by whatever motivates them to do good with free software. Even if it is money.
Volunteers are in it for the satisfaction of volunteering.
If you want anything beyond that as compensation for volunteering, you are by definition not volunteering.
Incidentally, those who receive monetary compensation for their time and work are known as professionals.
The same way maintainers make their decisions, the community is free to deal with it in any way shape or form. As long as money or malice or recklessness isn't involved, people should be free to do what they think is right, and the current maintainers aren't putting any roadblocks to prevent others from using the work in the way they want.
If that were was all there is to packaging - upstream developers could do the same job & have their CI/CD pipeline shoot out a .deb file.
However, it's not unheard of for package managers to maintain an evolving patchset that changes the default behavior and better integrates the upstream project to the rest of the distribution and its philosophy.
Improving defaults may be fine according to some. Removing major features advertised by the software due to political reasons is not fine.
My software is a victim of Debian maintainers as well: they chose to remove the default theme from our static site generator, because it was built on top of Bootstrap 3, but Debian only shipped Bootstrap 2 at the time in a global package (they also changed the bootstrap 2 theme to use symlinks to the global version). How is this “better integration with the philosophy”?
As a Debian stable devotee, this seems reasonable to me. If I wanted each package to bring along & manage its own dependencies, I'd use flatpaks.
> How is this “better integration with the philosophy”?
I'm guessing Bootstrap 3 wasn't yet in whatever release/channel your software was being packaged for?
Can't you imagine any possible benefits of not shipping bootstrap v2 and Bootstrap v3? Or do you just disagree with the Debian unstable -> testing -> stable philosophy? Dependency juggling is just one of the issues distro package maintainers have to wrangle with, that upstream maintainers typically don't care about - an upstream project can declare "this version requires the latest glibc", but distro packagers may have to patch around that because the latest version of glibc hasn't been through testing.
> there is no global /usr/lib to be concerned about
Aside from possibly the path being different, which is of no concern, how can the 2 above sentences reconcile with each other?
That's what some users seem to want today. It's why both Flatpak and Snap exist with the goals of letting upstream developers just CI/CD spit out a "universal" package for Linux and getting a more "Mac-like" (or "Windows-like" if you prefer) install experience with less waiting for package maintainers to get around to publishing upstream changes.
Admittedly, Flatpak and Snap aren't universally beloved either, yet, but the balance of what the job for a distro's package maintainers should be is definitely in shift.
That said it probably makes more sense for Debian to package a `keepassxc-nonet` alongside the default `keepassxc` so end users can choose the variant.
Wahey, isn't that what MS does with e.g. Outlook. Congrats Debian, you're reaching Microsoft's level!
There is no get out jail card here... just people volunteering their time, and a subset of users that feel they have some sort of entitlement. If I volunteer to pick up trash at my local park, would you demand that I pick up your garbage? No.. that would make you a jerk.
I'm an inactive Debian Maintainer and retired Ubuntu core dev, so perhaps my views are biased.. but I really think people should show these volunteers more respect.
"they're doing it for free, no one owes you anything" is always the argument people make when someone does something reasonably dumb and they need to defend the maintainers/devs. They don't owe anyone anything, but people DO HAVE _REASONABLE_ expectations of them.
In this instance the maintainer of the Debian package for KeePassXC has unilaterally made a choice.
In this case it’s features that were patched out - not plugins or a mere config change.
The Debian package wasn't shipping the correct default configuration in the first place, it's unfortunate but better late than never, and it's not like you can't switch to the keepassxc-full package.
The devs said they're not actually plugins, and that was quoted here hours before you commented.
https://github.com/keepassxreboot/keepassxc/wiki/Building-Ke...
-DWITH_XC_ALL=[ON|OFF] Enable/Disable compiling all plugins above (default: OFF)
You also owe it to your users to not mislead them by claiming that your modified version is actually the real FooBar.
https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
> This is now our fourth bug report because of the decision to neuter the base KeePassXC package in Debian
That's how it used to be in the past (and still is for enterprise distros because you might as well use the support contract you paid for). But lately users have gotten more savvy about talking to upstream directly, especially since more and more upstreams are now on easy-to-use websites like GitHub instead of mailing lists. That's still fine if users do their own diligence to ensure the issue is with upstream and not with the distribution package, but alas they don't all do that, leading to these spurious reports.
And I, as an end user, am absolutely fine with that, as a user of vim-nox package etc etc...
Do you have a non-trivial .vimrc/.vim directory?
Would you be accepting of the maintainer disabling a bunch of features and pushing those changes out under the main vim-nox package such that it breaks your existing install? Would it be reasonable to expect you as the end user to figure out what has happened and that you need to uninstall vim-nox and and install vim-nox-full?
I'm one of those users. If I'm loud, does that mean my opinion doesn't count anymore?
They were. apt shows the NEWS file during update when there's a change.
You definitely see it for several packages during dist-upgrades. Same in sid/testing except it can be any time though it's a rare event.
In case apt/dpkg is configured to ignore those, information still resides in /usr/share/doc/<pkg>
it'll also be put in the release notes when the next major Debian version is released.
I mean, distributions have already figured these things out 20 years ago, but I guess users nowadays expect these to be announced in Twitter or a pinned Github issue or something :-<
This really just breaks core functionality that exists and is expected by real users, under the guise of unnamed security risks...theres plenty of disabled options in Linux that are "potential" risks, so its a silly choice.
$ apt install keepassx
$ apt install keepassx-full
Choice made.
If it was so important they never should have packaged it in the first place. -Minimal option is the obvious reasonable choice, unless trying to be an arse to make a point, since you're changing a users choice after the fact.
Are we going to stop compiling sshd with plaintext pw options and root login, and suddenly?
If a user has an option enabled you don't like anymore, notify them, don't blindly remove functionality and say "your fault for not reading the changelogs".
Frankly the security claims ring more of hyperbole than anything
apt shows the NEWS file during update when there's a change. These users not only have chosen to actively ignore the warning that has been shown to them by default, they've also chosen to directly go to upstream to complain instead of first their distributions channels.
https://github.com/keepassxreboot/keepassxc/wiki/Building-Ke...
-DWITH_XC_ALL=[ON|OFF] Enable/Disable compiling all plugins above (default: OFF)
If KeepassXC is unhappy with the defaults, they can adjust theirs to reflect what they feel should be available out of the box.
Folks that disagree with a maintainer's actions are generally free to fork the project and maintain an alternative -- that's one of the primary features of open source software. And if end users prefer that new fork to the original maintainer's version, that'll probably be the one that survives.
But maintainers have no obligation to make their end users happy.
By their making the decision they think is best and that agrees with the philosophy of the distribution they're maintaining the package for? I'm glad they don't have to justify their existences to upstream and every "significant portion[...] of users."
> It's KeePassXC's job to secure the software and produce features that fulfill users' needs as they see fit.
You don't control free software after you've licensed and distributed it that way. The entire point of the concept is to make calls like this about anti-features. KeePassXC can feel free to comment on it, like anyone else. They can demand that Debian make available the modified sources. They can revoke any license to the use of trademarks. That's it.
If users only want to deal with KeePassXC, they can compile it themselves or use a portable version. If KeePassXC wants to deal with Debian users directly, they can host a package repository for their canonical version.
By the same argument we should remove encryption as well, because it increases the amount of code and thus the attack surface.
The physics of someone cracking my passphrase and the physics of someone cracking my Yubikey are both in the boil the oceans amount of energy.
I'm fine not letting a usb device masquerading as a keyboard have access to my password database.
Remember: "When you lose your YubiKey or someone else gets access to it, your database is not secure anymore."
You don't store your password on the YubiKey, you use it as a second factor in addition to your password.
Do you know what a YubiKey is when you argue against it?
They can do that... under a name that doesn't mislead people. Is that so hard?
I would be pissed if a FreeBSD package was some non-standard configuration.
> I would be pissed if a FreeBSD package was some non-standard configuration.
I'm of two minds here.
On one hand, I agree that I would like packages to be packaged as similar to upstream as possible (even if this has also caused annoying changes during upgrades).
On the other hand, I appreciate when package maintainers remove things like enabled-by-default telemetry (which is a whole another topic of its own).
Of course for both cases one should at least skim over the post-installation messages, or whatever they're called. To look for deprecation notices, additional instructions, messages like "if you need X feature please install such package", etc.
So if I don't read these messages, which appear right at the end of the install/upgrade process (can't miss them), that's my fault. If I don't do a zpool checkpoint before upgrading, that's my fault. If I don't verify important or major stuff (like my password manager, web browser, rebooting to ensure graphics drivers still work, etc) after the upgrade and before deleting the zpool checkpoint, that's my fault. If I didn't at least skim the list of package that were going to be upgraded, that's my fault. If I didn't backup my zfs mirror to a separate, plugged out drive before doing a major FreeBSD version upgrade, and the upgrade goes wrong, and I don't have any way to restore the pool to how it was before the upgrade, oh you better believe that's my fault.
(EDIT: Sorry for the long paddlin' reference but the TL;DR is that, if something breaks, half of the responsibility lies on the user.)
Changing topic back to TFA and Debian.
Whether or not the Debian maintainer followed proper procedure for such a change, is a good question because there's not only the maintainer, but also Debian itself.
So I'm kinda waiting to see if there's any response from someone higher up the Debian chain of command; if they (whoever writes the "Debian maintainer rules") consider this acceptable for a maintainer to do, or if they will issue a warning saying this was something not acceptable and "might lead to losing maintainer status if it repeats in the future".
As a user it defies my expectations to have software modified to remove functionality and retain the same name. This is a bit too opinionated for my tastes.