The KeePassXC Kerfuffle
lwn.net
lwn.net
While that's a nice soundbite in principal... Klode was incredibly rude on the bug report, didn't communicate with the upstream and (at the time) was seemingly unwilling to budge on the issue.
Actions have consequences and maintainers aren't above basic politeness just because their volunteer their time. This whole kerfuffle could've been avoided if he was just a bit nicer in his communication?
The post wasn't "hey look at this rude asshole" but "rogue Debian maintainer $makes_change." I would bet that most people aware of the story never even clicked through to the GH issue to see the tea.
I feel like he should either stop maintaining the Debian package or block White from contributing in some way. If they want to adhere to said code of conduct, of course... which was made -- first and foremostly -- for and by softies to avoid altercation.
What is a "softie"?
(I don't like the word. Just answering the question without agreeing that anyone should be called a softie.)
As I understand it, White is not a Debian contributor, and the discussions did not happen on a Debian mailing list.
So I'm not sure what Debian's code of conduct has to do with anything?
-- comment by Klode
IMHO, calling software someone works hard to maintain "crappy" is a personal attack. So Klode isn't innocent with respect to the code of contact either.
This is a really poor way to look at this.
Using this type of language is probably part of the reason the code of conduct exists.
People that work for free on something don't deserve this. No one deserves this. I'm particularly angered by this type of thing because I deal with horrible colleagues all the time. I'm working on getting away from this situation but the job market is not easy to navigate right now. No one should have to feel like the work they do is negatively impacting their mental health because some random on the internet has forgotten they're talking to another human being.
In fact, I'd go further and say it's exactly the use-case that should be being encouraged. As well as avoiding the issue of clip-board watchers, it also reduces friction and increases the likelihood of ordinary users being willing and able to use it.
Using a hardware key to unlock the database arguably is more of an edge-case, but conversely I'd argue that it's not acceptable to simply break that workflow.
So, IMO, Klode was very much the "computer says no" part of the analogy. He changed the process so the default was to turn away live use-cases.
A while ago KeePassXC published a glowing audit report, but the report just ignored the scary stuff -- i.e. the things being disabled here like browser integration. I took a quick look, and thought the design could use some work -- but when I tried to discuss it they were very dismissive.
I did file a bug for one of the vulnerabilities we discussed, but I don't think they changed anything and didn't seem interested.
With the argument of the maintainer he might as well delete the package since without any functionality nothing can be exploited.
I always thought keepass key feature was the 'Global Auto-Type' that works in most applications
Sometimes a pretty good compromise is found, like with PHP, where there's a core package, and additional packages for a common subset of extensions.
Here, though, I both understand, and don't understand.
It's one thing to disable the favicon downloading, and Have I been PWNed integration. That's a fairly obvious case where the security is improved.
But browser integration, hardware key support, and TOTP integration are more nuanced cases. I know I would have a hard time using a password manager without browser integration...especially with increasing security friction adding up.
Security is very important. But security is not the end goal, the goal is to provide the best *practical* defense possible. Browser integration, TOTP integration, passkey support, and hardware key integration all can add enough convenience to actually improve security.
The features could just be a preference setting and everyone can use the same package, just like we don't have a Firefox package with fingerprint resistance enabled and one with that feature disabled.
$ apt-cache depends npm | wc -l
151
> (I'd rather isolate the password manager so it can't access the network, etc.)
That won't help either: https://xkcd.com/1200/
Any program can alias the Keepass command or menu entry. It takes a vulnerability in any of, eh, *checks dpkg -l | wc -l*, over 4000 packages to supply-chain-attack my desktop setup
This is infantilizing and demeaning to users. I'm reminded of Douglas Gwyn's quote "Unix was not designed to stop you from doing stupid things, because that would also stop you from doing clever things."
> (I'd rather isolate the password manager so it can't access the network, etc.)
You can do that without needing to compile a different version though. E.g., "flatpak --user override --unshare=network org.keepassxc.KeePassXC", or manually creating an empty network namespace to do the same for programs not available in Flatpak.
Happily, flatpak is not part of a default Debian installation.
I saw the notification when I upgraded the package so I removed it after and installed the full version. But, a few days later a coworker complained about some script using KeePassXC from the cli, because he did not see the notification and was missing the secret agent.
I think that they should gone for upgrading keepassxc packages to the new keepassxc-full and deprecating the old keepassxc package in favor of a new keepassxc-lite for new installs.
Arch Linux does this best.
-DWITH_XC_NETWORKING=[ON|OFF] Enable/Disable Networking support (e.g., favicon downloading) (default: OFF)
Thanks for downplaying the voice of the affected users, but also how would they learn than? Like in this case, it would have just gone into stable without pushback
"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."
> 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
If you are running testing or unstable and not reading NEWS files then I think it's your fault - or is that victim blaming :P
However, I do feel like this is yet another situation where just a little more communication and a little less hostility would have made a world of difference. More and more I think that computer science and related programs should probably include a mandatory communications course or two (not a fluff comms course that I often see), and maybe a conflict resolution course. I think a non-negligible amount of problems in open source would have been entirely avoided.
Klode was dismissive, but Johnathan White also sounds like a bully
The entire drama was unnecessary
https://lists.debian.org/debian-security-announce/2008/msg00...
So no, for something security-specific like KeepassXC, Debian maintainers do NOT get the benefit of doubt.
If they start copycating other distro, I will move to other distro.
So many distro options, why keep bullying to make them the opposite of what they're known for.. or make them indistinguishable
It may not be automatically wrong either because there are a few imo weak arguments that some of the extensions outweigh their own increased attack surface by increasing usage of better passwords genetally and decreasing usage of the copy-paste buffer, so I won't go as far as to say that.
But what is wrong is acting like the opposite is also automatically wrong.
KeePassXC tooted something like "warning: debian removed all functions" obviously ridiculous unless they removed the function of encrypting and storing passwords. I replied "warning: KeePassXC has confused KeePass users with Lastpass users"
If you want convenience over all else, then why are you even using keepass? Google and MS will happily store all your passwords for free and in the cloud and automatically fill them into forms. So convenient! Let alone onepass/lastpass etc.
Security is not incidental to this particular apps purpose, it's the central and indeed only purpose.
"This is why no one should use debian"? What a ridiculous statement.
That's an entirely reasonable position when deciding which features to enable when adding a new package to Debian. But it's not reasonable to rip existing features out from under people.
I said it could be considered a bug (in the distribution) to have included those features by default.
I don't personally use (or knew of) any of the network features in keepassxc, but this is the kind of change that you announce in one release, explaining how people that use it can keep using it, and then apply in the next release. Or, indeed, just make a second package for those who want the hardened setup.
There is an argument for the hardened version being the default, but moving from featureful to hardened is a significant change and warrants more than just pushing it and waiting for people to trip over it
It's not just the random picking of fights, it the needlessly dickish tone in all the comments too. And the suggestions are just wild too, ranging from "Why not re-architect the entire application so we can carve chunks out of your product nice and easy" to "I, some guy, have decided which parts of your product are important, and I've turned off the ones I don't like". I also like the guy who snuck in quite quickly, dropped an answer that totally solves the problem via the package manager, but seems to have largely been ignored.