This is what keep me using debian.
Debian have (at least) three flavour of vim, depends on I want lua python ruby or x11 supports.
I can install what I need without pulling in gigabytes of dependency.
If they start copycating other distro, I will move to other distro.
Exactly, recently most discussions around Debian have been "why is it not more like distroX" by people who probability never been interested in Debian to begin with
So many distro options, why keep bullying to make them the opposite of what they're known for.. or make them indistinguishable
Agreed. It's ok to find the extras useful, but it's not automatically right to include them let alone arm them by default.
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.
It's merely the slightest of inconvenience that the default case is safe and you have to click like 2 extra clicks to install and activate more attack surface.
> it's not automatically right to include them let alone arm them by default.
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.
It's entirely reasonable to say that a bug was fixed. People were accustomed to the bug? Oh well. That tiny inconvenience from having to react to the change is granted. Correcting the bug simply outweighs that.
Long-term Debian user here. Deviating from the featureset offered by the upstream package that had been stable since forever is an unexpected move. Patches usually fix bugs or improve system integration. It is not normal that running apt upgrade breaks a setup.
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
One of the many reasons I refuse to use Debian. You just don't get this kind of BS on Arch Linux, you get to chose what you think is right not what some maintainer decided is correct.
You usually don't. But if maintainer made such a controversial move it is very easy to fork-off the package and share with others. I'd expect a "real-keepassxc-not-some-braindead-nerfed-one" appears on AUR before I hit the problem.
Usually there's a binary package Compiled to whatever "upstream" considers stable. And then there are lots of AUR Packages, some binary, some src with variations.
Arch Linux has a policy of not deviating from upstream unless necessary. Their maintainers are unlikely to decide on compiler flags that specifically go against the KeePassXC developers wishes.
Arch isn't special. On Debian, or any other distribution, if you don't like how a component works you can still compile and install it from source yourself.
And this is the point where we all sit back, and let out a breath of relief that we don't have to deal with those open source assholes.
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.
>Maintainers should be able to screw up in public without fear of an internet pile-on.
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?
Maybe but he was going to get the pile-on no matter what he actually said so long as he stood firm on his decision so I'm not sure that's relevant. Yes he was a jerk in the Github issue, not defending that, but people didn't pile on because he was rude, they piled-on because of the actual change.
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.
How is this a debian maintainer going rogue?
Maintainers making changes to default package build flags is quite normal and should be expected.
These changes were even requested in the public bug tracker.
While there may have been an initial pile on, it could've abated pretty quickly if he was nicer and was willing to discuss it. Most of the pile on was exacerbated by his attitude.
Like everything in the ever-welcoming Linux uwuorld, Debian also has a code of conduct. Personal attacks seem to be against it, and Klode got /very/ attacked in this situation.
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.
> Users who need this crap can install the crappy version
-- 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.
> 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.
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.
The reason for the pile-on wasn't for screwing up. It was for refusing to correct his screw-up after it was pointed out. Consider people who are declared legally dead but are still alive. If all it takes to fix it is showing up at a government office with some ID and saying "hey, look, I'm still alive", then a pile-on isn't deserved. But if the government workers all just say "the system says you're dead, and dead people can't come back to life, so there's nothing we can do", then they all do deserve to be raked over the coals until they change their mind.
This could be interesting. Can the dead be charged with crimes? Can they be posthumously convicted? I’m sure the system would quickly find that the party in question is in fact alive in this case, but fun to ponder idly on.
Except on this analogy, Klode was the person claiming the rational "hey look I'm alive" approach, whereas his detractors were the ones using loud campaigns because they relied on edge-case "advantages" conferred by the "computer says no" system, and demanding people showing up alive with IDs at hand be turned away on the spot as the default option.
I'm not sure that using a browser integration rather than having credentials pass through the clipboard really counts as an edge-case.
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.
This also disabled features which increased security like the browser plugin. The browser plugin increases the attack surface by adding more code but at the same does a lot for security by making sure to check domain names and avoid using the quite vulnerable X clipboard.
With the argument of the maintainer he might as well delete the package since without any functionality nothing can be exploited.
I think this really highlights the difficulty of squaring software with a lot of configuration options and one-package-per-program binary package management.
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.
It's always a trade off between security and convenience, and we should have cordial robust discussions about where that line is. This was anything but that.
I certainly have some opinions about this whole thing, but I think both sides of the argument have been hashed out a number of times already.
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.
The Debian maintainer switched to building it with the default configuration!
The default build is networking OFF. Same for Yubikey, browser integration, etc.
-DWITH_XC_NETWORKING=[ON|OFF] Enable/Disable Networking support (e.g., favicon downloading) (default: OFF)
Does anyone know why these are compile-time flags anyway? Some people are going to want to use it and some aren't. Needing to rebuild to switch this configuration flag is prohibitive for a lot of nontechnical users, and a hurdle for everyone else using binary release distributions.
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.
If deploying this to end users, you may not want them to be able to footgun themselves/your org, and if you only partially trust the code, you might not want it to be able to easily turn these features on. It's not 100% (I'd rather isolate the password manager so it can't access the network, etc.)
If dependencies are considered a risk without any indication of anything wrong with any particular ones, npm should be the biggest footgun ever and probably removed from the repositories altogether!
$ apt-cache depends npm | wc -l
151
Over a hundred separate projects are being pulled in for this one command. If only this were a niche project nobody ever uses for anything important.
> (I'd rather isolate the password manager so it can't access the network, etc.)
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
> you may not want them to be able to footgun themselves
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.
> Maintainers should be able to screw up in public without fear of an internet pile-on.
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
I read the more important earlier version of that part by the maintainer
"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."
> the only users who are actually at risk of a surprise change to the keepassxc package are those running testing or unstable releases
> 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
I have no issue with the maintainer's decision to default to a safe set of features but it could have been handled better.
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.
The flags to disable network access also disable several security features. IMO that's a bug in the flags, there should be a way to disable non-security-increasing features (e.g. favicon fetching) while keeping security improvements (e.g. bypassing the clipboard with the browser plugin & using hardware keys).
Distro maintainers should absolutely have the ultimate decision on how they distribute software, according to the project objectives, that is why we choose/trust/like some over others
Klode was dismissive, but Johnathan White also sounds like a bully
Except Debian is notorious for breaking OpenSSL's security by "helpfully" removing code that provided entropy for keys without understanding why it was there (Chesterton's Fence):
63 comments
[ 3.3 ms ] story [ 130 ms ] threadIf 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.
* https://news.ycombinator.com/item?id=40320166
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.
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.
Arch Linux does this best.
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.
> (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.
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
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.
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.