KeePassXC Debian maintainer has removed all network features(fosstodon.org)
fosstodon.org
KeePassXC Debian maintainer has removed all network features
https://fosstodon.org/@keepassxc/112417353193348720
349 コメント
Looks like pretty reasonable decision to me - network features and browser integrations are huge potential holes / exploit entry points. And without network-related features and only running the trusted databases, the tool should be impossible to exploit even if exploits are found, which is a very desirable trait for something as important as password manager. Even original maintainer agrees [1].
Remember, the full network-enabled package is present in debian as well - so all the network features are "apt install keepassxc-full" away, for users that want it.
Two minor comments: calling your upstream "crappy"[0] is probably not the most productive way for package maintainer to act. Also, I am not sure if the package names (keepassxc vs keepassxc-full) are best for Debian users - something like keepassxc-lite and keepassxc-full might be more informative.
[0] https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
[1] https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
Remember, the full network-enabled package is present in debian as well - so all the network features are "apt install keepassxc-full" away, for users that want it.
Two minor comments: calling your upstream "crappy"[0] is probably not the most productive way for package maintainer to act. Also, I am not sure if the package names (keepassxc vs keepassxc-full) are best for Debian users - something like keepassxc-lite and keepassxc-full might be more informative.
[0] https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
[1] https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
I think the solution suggested by drawks seems clearly the correct choice:
> I think the proper solution would probably be to package both a "-full" and "-minimal" version of the software and utilize Debian package meta-data fields to define a Conflicts relationship between the packages and tag them also both with a Provides for keepassxc and also add a tag Replaces: keepassxc to the -full build so that during a package upgrade an existing user would be provided the version that continues to provide the features of the package which is being upgraded/replaced while new users can choose for themselves which of the versions they'd like to install
https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
Why would this _not_ be the obvious choice?
> I think the proper solution would probably be to package both a "-full" and "-minimal" version of the software and utilize Debian package meta-data fields to define a Conflicts relationship between the packages and tag them also both with a Provides for keepassxc and also add a tag Replaces: keepassxc to the -full build so that during a package upgrade an existing user would be provided the version that continues to provide the features of the package which is being upgraded/replaced while new users can choose for themselves which of the versions they'd like to install
https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
Why would this _not_ be the obvious choice?
Meanwhile in Arch land (possibly other distros as well), the fwupd package (which I imagine to be a fairly common package to be installed among the user base) has been silently configured to depend on passim, which spins up an open web server on 0.0.0.0:27500[1] without any(!) explicit user consent whatsover. Passim then uses GnuTLS, which is famous for containing more holes than Swiss cheese [2][3].
Absolutely insane to me, and I would not be surprised if there's an xz type of exploit hidden somewhere in the chain.
[1]: https://github.com/fwupd/fwupd/issues/6721
[2]: https://news.ycombinator.com/item?id=7347500
[3]: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=gnutls
Absolutely insane to me, and I would not be surprised if there's an xz type of exploit hidden somewhere in the chain.
[1]: https://github.com/fwupd/fwupd/issues/6721
[2]: https://news.ycombinator.com/item?id=7347500
[3]: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=gnutls
I would like to believe package maintainers should operate under a principle of least astonishment and not disable core features (and not plugins, despite currently 25 entries of that word in this comment section) unless there's a documented or at the very least probable risk, none of which seem to be the case here. KeePassXC has many features but none that would on their own, and without explicit user intervention, be a likely source of vulnerabilities. The browser integration must be toggled on before you can even set it up, likewise for (I believe) every other function disabled with this flag, so a -minimal package may have been more appropriate. The small subset of users that could benefit in some indeterminate future from this change must be incredibly small, while it's going to be a serious annoyance for anyone using the browser integration, a function that's generally far safer than clipboard access. It also doesn't feel in line with the project's vision:
Our goal is to create an application that can be used by anyone while still offering advanced features to those that need them.
Our goal is to create an application that can be used by anyone while still offering advanced features to those that need them.
Considering it would be completely possible to make this distinction without breaking existing users, it's difficult to see this as anything other than a bad decision by the Debian package maintainer. While having the ability to have KeepassXC without networking features is certainly nice, considering the browser integration to be a niche feature is just severely out of touch; I would be willing to place real money on betting that more than half (probably well over half) of users of KeepassXC in Debian today want features that will be surprise-disabled because the maintainer chose a way of doing this that would break existing users to impose their opinion.
It is ultimately their decision to make, but that doesn't mean it is a good one, I contend it is not.
It is ultimately their decision to make, but that doesn't mean it is a good one, I contend it is not.
From a KeePassXC maintainer:
> In the lead up to this thread I received three reports of this new package method crippling people's workflow. One report was a user who couldn't open their database anymore because the yubikey feature was removed. Let that sink in for a second. People who lose access to their most important secrets can sometimes do irrational things in the moment of panic.
https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
> In the lead up to this thread I received three reports of this new package method crippling people's workflow. One report was a user who couldn't open their database anymore because the yubikey feature was removed. Let that sink in for a second. People who lose access to their most important secrets can sometimes do irrational things in the moment of panic.
https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
IMHO is a downstream maintainer is going to change a package in a way that doesn't have the intent of the upstream project, it should be published under a different name and that maintainer deal with all bug reports caused by their modified version.
For folks interested this issue on GitHub seems to have the latest comments.
https://github.com/keepassxreboot/keepassxc/issues/10725
https://github.com/keepassxreboot/keepassxc/issues/10725
Title is wrong. The original post said maintainer has removed ALL features, not only networking features, and this was true, ALL optional features, including entirely offline features, were turned off during build.
Horrid PR for Debian. The decision is ignorant and capricious and makes Debian seem like a personal toy project instead of a FOSS cornerstone. On top of that the Debian maintainer then responds by calling upstream "crappy".
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529
I don't think the Debian maintainer is aware that the favicon download feature is optional and manual. You literally need to press a button labelled "Download favicon" before it connects to the internet.
I don't think the Debian maintainer is aware that the favicon download feature is optional and manual. You literally need to press a button labelled "Download favicon" before it connects to the internet.
Good discussion here: https://github.com/keepassxreboot/keepassxc/issues/10725
I have already been using bubblewrap[1] to isolate KeePassXC from the network and more (the only access it has is to its own private directory and a hardened Wayland socket[2]). I wouldn't recommend relying on devs or maintainers to do application isolation work for you.
[1] <https://github.com/containers/bubblewrap>
[2] <https://git.sr.ht/~whynothugo/way-secure>
[1] <https://github.com/containers/bubblewrap>
[2] <https://git.sr.ht/~whynothugo/way-secure>
This maintainer does not respect upstream developers. He must step down and pass this package to someone who respects the upstream developers and their judgement. He must not keeping this name hostage and damaging the brand.
I have a lot of respect for the Debian project but every now and then one of their maintainers does something completely stupid and unreasonable and expects applause
It's crazy the amount of power maintainers hold over someone else's software. This reminds me of the time when Fedora maintainers disabled GLES1 support in Mesa because "nobody should be using it anymore (there are newer OpenGL versions)", disregarding the fact that GLES1 was well and fully maintained upstream, and was and is still the only option on many devices.
> 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
While that sounds like a reasonable argument, I think it misses the fact that you need reasonable usability to get users to use your product. E.g there's no way my wife will use KP of she doesn't have autofill, and she'd then revert to someone else's computer like lastpazs or 1password instead, which I'd argue is a worse solution in all ways possible.
The other thing that makes me question this a little, is removing yubikey support and auto type. While you don't get the full advantage of MFA, having a rotating encryption key is still an additional layer of protection. Meanwhile, without auto type you will need to copy-paste usernames and passwords - and listening to the clipboard is much easier than building a key logger.
I mean, if really what you're looking for is barebones, you can also not use a password manager and come up with a cypher instead.
While that sounds like a reasonable argument, I think it misses the fact that you need reasonable usability to get users to use your product. E.g there's no way my wife will use KP of she doesn't have autofill, and she'd then revert to someone else's computer like lastpazs or 1password instead, which I'd argue is a worse solution in all ways possible.
The other thing that makes me question this a little, is removing yubikey support and auto type. While you don't get the full advantage of MFA, having a rotating encryption key is still an additional layer of protection. Meanwhile, without auto type you will need to copy-paste usernames and passwords - and listening to the clipboard is much easier than building a key logger.
I mean, if really what you're looking for is barebones, you can also not use a password manager and come up with a cypher instead.
Should bave left the original KeyPassXC Debian package alone and ...
Instead to create a `keypassxc-offline` package with those tweaks.
Instead to create a `keypassxc-offline` package with those tweaks.
This should have been handled the same way Mozilla handles Firefox. KeepAssXC developers, file for trademark protection and then send a cease and desist to Debian legal.
If they want to misrepresent your application to Debian users, they'll have to do it under a different name or not at all.
If they want to misrepresent your application to Debian users, they'll have to do it under a different name or not at all.
I see in this an attitude that's become increasingly common since the 2010s among developers as well as software companies regardless of open source or proprietary - "We know what's good for you, the end user and we will decide on your behalf." and use this as an excuse to strip out features that had been long available. Firefox is a classic example.
In stark contrast to the previous norm of highly customizable software that catered to both newbies and power users. Right here we see the example of the maintainer unilaterally deciding to strip out a feature that's already been disabled, just because he decided he knows better what KeepassXC users ought to do.
In stark contrast to the previous norm of highly customizable software that catered to both newbies and power users. Right here we see the example of the maintainer unilaterally deciding to strip out a feature that's already been disabled, just because he decided he knows better what KeepassXC users ought to do.
We used to deploy on Debian at my previous place, and we hit this sort of shit all the time. Maintainer ripped out features they disagreed with (political reasons, or just engineering/product taste), maintainers changing the configuration files to things that suited them better, etc.
I understand it's all volunteer work, I understand it's open source so anyone can add their own custom packaging, on top, but Debian (the OS) certainly uses the ecosystem as a selling point, and it really can come back to bite you.
I understand it's all volunteer work, I understand it's open source so anyone can add their own custom packaging, on top, but Debian (the OS) certainly uses the ecosystem as a selling point, and it really can come back to bite you.
A password manager without browser integration is essentially dead in the water. Seems like what they're shipping is unusable for most people. We all know 'unusable FOSS' cliché but in this case it actually applies.
These kind of "feature changes" in Debian packages is one reason I stay away from Debian.
And it's not just features that might change. A Debian maintainer introduced a bug in the OpenSSL random number generator making it insecure, a couple of years ago.
And it's not just features that might change. A Debian maintainer introduced a bug in the OpenSSL random number generator making it insecure, a couple of years ago.
I think it's correct for the default package to be the safest-possible one. It's a password manager not an mp3 player.
Yes it's annoying that an existing behavior will change, but that problem is not more impportant than the problem of what should be the default behavior of a security app.
keepassxc should have always been like that by default and all the added conveniences that also add bug-surface and attack-surface should have always been things you have to go out of your way to add.
It wasn't and so now to fix that error requires a disrupting change, but that is not enough excuse for not fixing the error.
Yes it's annoying that an existing behavior will change, but that problem is not more impportant than the problem of what should be the default behavior of a security app.
keepassxc should have always been like that by default and all the added conveniences that also add bug-surface and attack-surface should have always been things you have to go out of your way to add.
It wasn't and so now to fix that error requires a disrupting change, but that is not enough excuse for not fixing the error.
I abandoned KeePassX (pre XC fork) when they made wonky changes ~10 years ago.
Use Bitwarden (optionally run your own sync server) or Keeper (for less technical people).
Use Bitwarden (optionally run your own sync server) or Keeper (for less technical people).
What is the big issue? The maintainer put up two packages, one stripped down and another with full functionality.
I'd say it's really good to have options so the user can choose themselves.
I'd say it's really good to have options so the user can choose themselves.
So in the end they reduced the attack surface for a program running on your computer by increasing the attack surface on the meatbag operating the computer? (i.e. browser integration which is the only effective thing against phishing)
Seems like a good deal /s
Seems like a good deal /s
Fortunately Debian maintainers have a fantastic track record of writing ad-hoc patches for security-sensitive software.
This reminds me of the time years ago when the Debian maintainer of Chromium decided to unilaterally disable the ability to install extensions. Thankfully, more pragmatic minded people prevailed and the patch was reverted.
This also reminds me of a time many many many years ago when Debian removed the kernel interface that provided the ability to load binary firmware into network cards and broke networking for me.