24 ms·

KeePassXC Debian maintainer has removed all network features

312 points by CuriousIndian 2y ago

PlutoIsAPlanet 2y ago
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.
- bananapub 2y ago
  not sure why you're commenting without even reading the linked 200 character post? the maintainer has enabled all plugins (including network stuff) in the keepassxc-full package, the keepassxc package will be just the basics with a much better security posture. that's obviously completely fine and completely within the remit of a maintainer, the entire complaint is about this being a change.
  - milliams 2y ago
    As stated in the GitHub thread [1]: You fundamentally misunderstand our program when you use the word plugin. These are built in features, not plugins. The features can be enabled as desired by the user and they come disabled by default. This change to not compile and ship these features in the base keepassxc package does nothing besides create angry (or confused) users. [1] https://github.com/keepassxreboot/keepassxc/issues/10725#issuecomment-2104508951 https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
    - bananapub 2y ago
      that seems completely irrelevant? plugin, compile time ./configure flag, whatever - package maintainers extremely routinely create multiple versions of a package for various reasons, from security (this case) to dependencies (Debian contains a emacs-nox package that is emacs compiled without X libraries to avoid dragging them in on servers, for example) to license reasons. again, all of the complaints are literally about the change, which the maintainer has decided to do in a disruptive fashion.
    - arp242 2y ago
      That Canonical guy is not coming off brilliantly there. I appreciate that reasonable people can disagree on the best way to package this, but these kind of strong absolute statements – together with calling useful features "misguided" and "crap" – is not great, to put it mildly. I'm pretty sure some compromise could theoretically be reached here. But not with that attitude. "It is our responsibility to our users to provide them the most secure option possible as the default"? You know what would be even more secure? To disable all networking in any program, and in fact, in Linux itself. Actually, it's even more secure to just not give people a computer at all. This is one of those stupid discussion-stoppers. These kind of Highly Opinionated Maintainers™ has always been what put me off from Debian (and by extension, Ubuntu). I want to use KeePassXC, not "KeePassXC as some random guy thinks it should have been".
      - trallnag 2y ago
        What's the alternative to Debian / Ubuntu now that CentOS is gone?
        lawn 2y ago
        Arch Linux and Void Linux are both worth a look I'd say.
        TheBicPen 2y ago
        I believe the zoomer response to this is "bruh"
        yjftsjthsd-h 2y ago
        Rolling-release distros are unlikely to fit into the same usecase as a slow-moving stable-release distro.
        arp242 2y ago
        AlmaLinux and Rocky Linux are continuations of CentOS; I have no experience with either but that would be the logical place to start.
        2y ago
  - jdbernard 2y ago
    The problem is that this will break all existing users who use those features when they update. One of the comments in the GitHub thread has a better path, IMHO: ship two new packages, a -minimal and a -full, and the user to choose, rather than silently break functionality (NEWS is fine, but not really read by user as everyone admits).
  - JohnTHaller 2y ago
    The default package should be named keepassxc-debian-limited or similar and the proper package should be keepassxc
    - bananapub 2y ago
      OK? that has nothing to do with what I was correcting: > 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. the downstream maintainer didn't "change a package in a way that doesn't have the intent of the upstream project", they altered the config flags in one package and made another with the previous flags. the maintainer is being a dick, but not in the way the OP suggested.
      - Dylan16807 2y ago
        > the downstream maintainer didn't "change a package in a way that doesn't have the intent of the upstream project", they altered the config flags in one package and made another with the previous flags. They altered the config flags in a way that doesn't have the intent of the upstream project. And I would classify build config changes as a subset of "changing a package".
    - Dah00n 2y ago
      Use JohnTHallerNix and it can be. Debian is again taking care of their users. Unlike upstream, Which isn't new. Did he do it in the best way? No. Did he do the right thing? Absolutely.
    - hi-v-rocknroll 2y ago
      It's the tyranny inherent to dependency-hell monolithic package management. nix avoids this problem by permitting multiple versions and flexible configurations of the same package.
  - nulld3v 2y ago
    But that's not what they disagree with. They are saying you shouldn't have a package called "keepassxc" if it is missing a ton of features from upstream KeepassXC. You should name it something different instead. So you shouldn't have "keepassxc" and "keepassxc-full". Instead you should have "keepassxc" and "keepassxc-minimal".
    - vlovich123 2y ago
      But it’s a valid build configuration option provided by upstream. Not sure I follow this line of reasoning.
      - nulld3v 2y ago
        Sure, I think that's a reasonable stance. If upstream agrees that such a configuration is a valid distribution of KeepassXC and can be branded KeepassXC, then that's up to them. I would probably disagree with upstream in that scenario just from a UX perspective, but I would understand both sides. But in this case, upstream has responded and clearly indicated that they do not want the minimal distribution of KeepassXC to be branded as the main "keepassxc" package: https://github.com/keepassxreboot/keepassxc/issues/10725#issuecomment-2104381335 https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
  - WesolyKubeczek 2y ago
    Because I run and upgrade and suddenly all my shit stops working without warning, that's why. It's not how things should be done.
- donio 2y ago
  The WITH_XC_NETWORKING build option is off by default so the developers have obviously intended this to be a valid build configuration.
  - fallingsquirrel 2y ago
    Sure, but that doesn't change the fact that a point release suddenly broke everyone's workflows and is causing maintenance headaches. I don't think the technical minutia of how exactly things were broken is the issue. If Debian shipped a Linux kernel point release that disabled networking I think people would be similarly upset, even though it's also just a build option and intended to be a valid build configuration (and would even more secure!)
    - Dah00n 2y ago
      >If Debian shipped a Linux kernel point release that disabled networking That is not comparable. "If Debian shipped a Linux kernel point release that removed a risky networking plugin and some disabled-by-default plugins and made a -full version" that would be comparable.
      - MatthiasPortzel 2y ago
        It’s exactly comparable. The browser-autofill functionality in KeyPassXC is not a plug-in and it’s not risky. The person saying that is the Debian maintainer.
      - nulld3v 2y ago
        Hmm, excluding the comment about the missing "-full" version, I don't see how it is not comparable. There is nothing that makes the networking code in KeepassXC more "risky" compared to the networking code in Linux.
    - kasabali 2y ago
      > that doesn't change the fact that a point release suddenly broke everyone's workflows BS. This change was in Debian sid/testing. That's what it's for. Debian stable users' workflow hasn't been broken.
- JohnTHaller 2y ago
  Either that or it should indicate to the end user that it's an unsupported package. Maybe showing up as KeePassXC-Debian or KeePassXC-Unsupported and have the developer's contact details (website etc) removed from About and replaced with the Debian details for support. A downstream maintainer making small changes to fit within the OS that doesn't meaningfully affect the app is fine. A downstream maintainer modifying an app and removing core functionality so the upstream dev gets a ton of grief is not.
  - deleted 2y ago
    [deleted]
- yencabulator 2y ago
  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) https://github.com/keepassxreboot/keepassxc/blob/develop/INSTALL.md https://github.com/keepassxreboot/keepassxc/blob/develop/INS...
- yjftsjthsd-h 2y ago
  > and that maintainer deal with all bug reports caused by their modified version. I appreciate that it often doesn't happen, but that's supposed to be the default flow regardless: If you're using a distro-provided package and hit a bug, you're supposed to open a bug report against the distro package, and then the maintainer looks at it, and if the bug came from upstream then they file a bug with the upstream project. This is helpful because 1. the package maintainer is probably familiar with the package and can provide initial triage/analysis, possibly even being able to fix the bug outright before going upstream to share the fix, and 2. as you note, distro packages frequently carry some amount of patching and the maintainer should verify whether the bug is in their packaging or the upstream source code. Unfortunately, many users default to reporting upstream first:( So in practice this is a concern, but it's really not supposed to be.
HieronymusBosch 2y ago
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
- okl 2y ago
  Debian maintainer, Julian Klode, has a "pointed" opinion: > 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.
  - lupusreal 2y ago
    [flagged]
    - nulld3v 2y ago
      They removed other non-networking features too. E.g. even autotype was removed. At that point why not just store your passwords in an encrypted notes app?
      - zikduruqe 2y ago
        Just use https://www.passwordstore.org https://www.passwordstore.org
      - lupusreal 2y ago
        I use KeePassXC, but not any network features or autotyping, because I like the password generation and because the interface is nice. I previously used Vim's old encryption feature (since removed I think?) and I think KeePassXC as I use it is a good upgrade from that.
derkades 2y ago
Good discussion here: https://github.com/keepassxreboot/keepassxc/issues/10725 https://github.com/keepassxreboot/keepassxc/issues/10725
rurban 2y ago
[flagged]
- jdbernard 2y ago
  The most secure system is the system with no features! Let's delete everything. #nofeatures #securityonly
  - doubled112 2y ago
    Guess this is it. I'm powering everything down for security reasons. To the woods I go to build a cabin.
    - Takennickname 2y ago
      They made a netflix documentary about the last guy who did that. He wrote a pretty good manifesto.
  - rurban 2y ago
    Nothing is deleted. Just the default options are now used, as intended and announced upstream. How should a debian openssh be called, with custom patches to integrate systemd logging, enabling all old and insecure cyphers? Or a debian openssl with all legacy cyphers enabled?
    - nulld3v 2y ago
      > as intended and announced upstream Meanwhile, from a maintainer of the KeepassXC repo: > Good luck to you. Really bad decision. We will be sure to let everyone know. https://github.com/keepassxreboot/keepassxc/issues/10725#issuecomment-2104430596 https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
  - Brian_K_White 2y ago
    [flagged]
theamk 2y ago
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#issuecomment-2104401817 https://github.com/keepassxreboot/keepassxc/issues/10725#iss... [1] https://github.com/keepassxreboot/keepassxc/issues/10725#issuecomment-2104512907 https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
- Arnavion 2y ago
  There's one way in which browser integration improves security vs not using it, which is that the browser extension checks the page URL before filling in the credentials, while the approach of manually copy-pasting credentials is vulnerable to typo- and homoglyph-phishing.
  - JeremyNT 2y ago
    This is essential to my own usage of KeepassXC. I never copy/paste from it into a browser and appreciate having this first line defense against phishing.
  - tuetuopay 2y ago
    This. So much this. I don't even understand how browser integrations are not universally thought as a core part of a password manager. With all the phishing that's going along, it's really the last line of defense. Oh and I'm not only talking about elderly relatives and such. Modern phishings are very very well made, and there's one going on to steal Steam accounts that I would have likely fell for (and I consider myself pretty good on the matter).
chomp 2y ago
Seems like a positive change to me.
- brnt 2y ago
  They disabled all plugins, not just those that may access networks. This is not good, it's nonsensical.
  - Brian_K_White 2y ago
    Thinking browser or other local integration is not as dangerous as network features is nonsensical. All of the disabled features are expendable. I never used any even while they were in there. Yet I do use keepassxc all day every day for the one job it actually does exist to do. Convenience and necessity are two different things. You want conveninece, and you're not wrong to want it, but you don't need it, and your want of convenience is not important enough to make the base utility when it is a password manager and not a gif editor less safe than it could be by default. It is correct that if you want to trade away safety for convenience, that you have to go out of your way to add that yourself, even if most people will choose to do that, and even if the previous default was backwards and it's now ever so slightly disruptive to correct that error now.
    - timw4mail 2y ago
      Absolute security means you can't do anything. Too much security friction can easily lead to *much more insecure* workarounds.
      - Brian_K_White 2y ago
        Somehow, I have been using the same app without any of those features. So, the idea that the app is not functional or useful without them is bullshit. As for friction leading indirectly to less security through user behavior... how many clicks and how many seconds is it to install the full version? So, yet more bullshit.
alyandon 2y ago
Gutting the functionality that upstream has built into a piece of software and then publishing it under the same name is dubious at best. If they want to go this direction they should publish as a fork under a different name so upstream doesn't get constantly barraged by complaints of users having issues. 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.
- Dah00n 2y ago
  They didn't "gut what upstream built". He published it without plugins and made a -full version that include plugins. If plugins are plugged in as default it isn't a plugin but a built-in feature. This is the correct way.
  - tdb7893 2y ago
    Default plugins is a very common pattern and often what users want. There can be technical reasons but also for common features it's way to have them as opt-out instead of 99% of people needing to opt-in to the same stuff
  - bananenpubs 2y ago
    He published it w/o core package functionality. There are no plugins with KXC, that is one of their main arguments: don't rely on 3rd party code, bring it all inhouse, where it can be checked / maintained.
    - redeeman 2y ago
      as others said, core functionality that UPSTREAM THEMSELVES decided not to include in default/recommended build instructions?
      - 2y ago
2OEH8eoCRo0 2y ago
It sounds like a necessary but painful change if we want secure by default.
- bananenpubs 2y ago
  Speak for yourself, please, not for 'us'.
  - guilhas 2y ago
    [flagged]
unparagoned 2y ago
People always crap over LastPass, but when you ask them what they do, it’s some elaborate process relying on thousands of no name packages and devs.
lawn 2y ago
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.
- wswope 2y ago
  > a couple of years ago You’re bearing a grudge based on an unintentional bug introduced 18 years ago. Weak take and irrelevant to topic at hand.
charles_f 2y ago
> 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.
- Brian_K_White 2y ago
  [flagged]
rfoo 2y ago
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.
jeffalyanak 2y ago
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#issuecomment-2104845637 https://github.com/keepassxreboot/keepassxc/issues/10725#iss... Why would this _not_ be the obvious choice?
- rfoo 2y ago
  Because maintainers have an opinion and explicitly wanted to change the default.
  - jeffalyanak 2y ago
    That does allow you to change the default for users installing the packages and while ensuring that users who already have it installed don't lose functionality during an upgrade.
  - GorsyGentle 2y ago
    Perhaps, and that's not unreasonable in and of itself. But to do so in such a user-hostile manner? That's a bit over the top. A new minimal package, advertising it, and only then eventually making it the default would have been far, far more effective. If an engineer of mine pulled this on our user-base I'd have them reverting it in a heartbeat regardless of the technical merit. They already failed just in how they executed this and have burned good will, the technical merits no longer matter. Once you've lost the faith and trust of the user, it's over. The original request[0] was more or less simply a user asking for the networking to be removed, and follow-up to just have a -nonetwork variation. Instead, we have comments from the debian maintainer: The OP report: > Users who need this crap can install the crappy version but obviously this increases the risk of drive-by contributor attacks. The debian package description[1]: > See keepassxc-full if you absolutely need those. The PR[2] > Feature creep like SSH agent support, browser integration, Freedesktop.org secret storage, KeeShare pose undue risks for most users. Each one of these sends a message. And it was entirely avoidable with a bit of grace and kindness to the existing userbase. [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529 [1]: https://packages.debian.org/sid/keepassxc https://packages.debian.org/sid/keepassxc [2]: https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f8de487b12266a1cb7975e2b7df2e3a4#b3f55b8d9783f2ed27acfd1f0fe06dfc461e2aba_0_4 https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f...
Brian_K_White 2y 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.
- kernal 2y ago
  A password manager with a built-in MP3 player? That's my next project.
  - Brian_K_White 2y ago
    The songs could tell you where to find the post-it note within your record library. Let the hackers gain access to your google drive AND decrypt the db. :)
- Latty 2y ago
  Safest by what metric? Calling the browser integration a "convenience" feature only is just fundamentally wrong. Realistically the most common attack most users face is a phishing attack, removing the browser integration which checks the URL programmatically before filling the password opens the user up to being phished more easily (users check URLs less consistently and less reliably), so arguably this makes the package less secure in the real world.
- Spivak 2y ago
  Debian is somewhat inconsistent with this but it does have precedent for package to be package-minimal and a corresponding full- variant. Odd to just break users by doing this, should have been done with a major release when people expect breakage.
  - 2y ago
jchw 2y ago
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.
kernal 2y ago
I like this solution. He reduced the attack vectors in the base application by removing features a large majority of people don't use. And if they want these additional features then download the full version.
- nulld3v 2y ago
  > features a large majority of people don't use. I would be shocked if this was true. I have recommended KeepassXC to many of my friends and family and they all use at least one of the features that was in the removed list. To be fair, none of them use debian, but some of them do use other Linux distros. I don't use debian on desktop anymore on my main machine, but I did use BunsenLabs for a long time and even back then KeepassX (and afterwards KeepassXC) auto-type was a critical feature I used literally every day.
  - gr4vityWall 2y ago
    I never knew KeepPassXC could talk with my browser or interact with ssh until I saw this thread, and I've been using it for almost 10 years now.
coppsilgold 2y ago
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 https://github.com/containers/bubblewrap> [2] <https://git.sr.ht/~whynothugo/way-secure https://git.sr.ht/~whynothugo/way-secure>
Kwpolska 2y ago
[flagged]
0x_rs 2y ago
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.
DDiggler 2y ago
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 https://github.com/fwupd/fwupd/issues/6721 [2]: https://news.ycombinator.com/item?id=7347500 https://news.ycombinator.com/item?id=7347500 [3]: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=gnutls https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=gnutls
- workethics 2y ago
  Good to know. I think this should probably be it's own post
  - 1oooqooq 2y ago
    https://news.ycombinator.com/item?id=40322408 https://news.ycombinator.com/item?id=40322408
- 1oooqooq 2y ago
  why fish for fwupd? systemd-resolved which is everywhere, will open (at request) an LLMNR server (a.k.a. mDNS, nee microsoft netbios) on port 5355. With IoT everyone have access to your LAN, so now people are making sure linux also join the REDACTED party btw, fix for fwupmdg, since they have a low quality default conf file without commented out defaults: ``` # /etc/fwupd/fwupd.conf [fwupd] P2pPolicy=none ``` fix for resolved is commented out on /etc/systemd/resolved.conf `LLMNR=no`, and you probably also want `DNSStubListener=no`. heck here is a good default ``` # /etc/systemd/resolved.conf [Resolve] DNS=9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net FallbackDNS=127.0.0.1 ::1 Domains=~. DNSOverTLS=yes LLMNR=no DNSStubListener=no ```
  - 2y ago
tuetuopay 2y ago
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
- cyanydeez 2y ago
  This reminds me of the how to secure a trashcan from bears in yellow stone: the dumbest person and the smartest bear has significant overlap. Protecting a few dumb people means exposing a lot more people to attack vectors.
lawn 2y ago
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#issuecomment-2105085740 https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
- guilhas 2y ago
  Everyone using an offline password manager without having a backup might as well consider everything lost This sounds like emotional blackmail How many times I lost everything, hardware failure, updates that broke OS, using dd in the wrong drive...
  - valicord 2y ago
    How would a backup help in this scenario? The data is fine, it's the application that stopped working.
    - guilhas 2y ago
      If the yubikey stops working, you also loose access to the database So I would have a backup with a simple password, or even unencrypted in a USB somewhere
      - valicord 2y ago
        You backup the yubikey seed (whatever it's called) separately from the password db, so that the attacker still has to get 3 separate pieces of information (db, password, seed) to get the full access.
        guilhas 2y ago
        If you backup the "seed" hotp secret you can probably use any OTP client software to open the DB without needing the yubikey
TheChaplain 2y ago
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.
- SAI_Peregrinus 2y ago
  They made the default the stripped-down one, which removes security features like the anti-phishing prevention in the browser extension.
shmerl 2y ago
There was some comment about it. Basically, it's for security reasons. Those who aren't using those features wouldn't expect them to appear (especially sneakily). And those who are planning to use them will figure out what package to install. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529 This was the message from maintainers: Networking and all plugins have been moved into the keepassxc-full package. Feature creep like SSH agent support, browser integration, Freedesktop.org secret storage, KeeShare pose undue risks for most users.
- Dylan16807 2y ago
  Browser integration and autotype are not feature creep. Making everything copy-paste is bad for security.
nsajko 2y ago
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".
- gradientsrneat 2y ago
  Said maintainer also does dev work for Canonical. So this probably affects optics for Ubuntu too. Although, speculating charitably, maybe the maintainer knows something we don't about the upstream's security policies.
- FdbkHb 2y ago
  Debian maintainers are experts at touching things they shouldn't and creating a mess in the process. The worst case, by far, was when they broke the RNG of SSH key generation: https://jblevins.org/log/ssh-vulnkey#:~:text=In%20May%202008%2C%20a%20bug,systems%20should%20be%20considered%20compromised https://jblevins.org/log/ssh-vulnkey#:~:text=In%20May%202008.... Those guys are out of control and constantly having conflicts with upstream, I'm astounded to see the amount of support I see for debian in this thread.
cookiengineer 2y ago
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529 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.
vbezhenar 2y ago
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.
gr4vityWall 2y ago
The maintainer's position seems reasonable to me. A different package, compiled with the network features, is provided too. I like this as a default.
xcdzvyn 2y ago
Fortunately Debian maintainers have a fantastic track record of writing ad-hoc patches for security-sensitive software.
hi-v-rocknroll 2y ago
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).
- hiAndrewQuinn 2y ago
  I recently switched from BW to XC in the wake of their acquisition, and I have to admit, the mobile experience is just a little more annoying. But I sleep better at night knowing that I don't keep anything critical on servers I don't own.
  - hi-v-rocknroll 2y ago
    1. What acquisition? https://bitwarden.com/blog/ https://bitwarden.com/blog/ 2. You can run your own FOSS Bitwarden sync server. It even works airgapped. https://bitwarden.com/help/install-and-deploy-offline/ https://bitwarden.com/help/install-and-deploy-offline/
yawaramin 2y ago
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.
parasti 2y ago
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.
- YPPH 2y ago
  >power maintainers hold over someone else's software There's some subtle assumptions about ownership in this comment that aren't accurate, insofar as free and open source software is concerned. FOSS software is not "someone else's" software. They may own the trade mark, but by releasing the software under a FOSS licence, they lose the right to control the direction the software may take. I'm free to copy it, edit it, and redistribute it as I see fit. So are you. So is Debian.
  - parasti 2y ago
    That's besides the point. You can do whatever with the software, but it gets muddy when you then release it under the same name as the original. That name may not be trademarked, but it is still not yours to use.
    - deleted 2y ago
      [deleted]
    - YPPH 2y ago
      This simply is irrelevant. A FOSS licence fully permits what Debian has done here. So, that is beside the point.
- kasabali 2y ago
  Not even comparable. Debian users can choose between the stripped and full version of Keepassxc, unlike the MESA example above.
raverbashing 2y ago
Hissy-fits like these are one of the reasons there's never going to be a "year of the linux on desktop" But why do they care, right? Most people on their irc channel (that have a basement NAS may I add) agree with their decision. Now my bet is that your average Debian user does care about convenience. Replacing (default off) selection boxes with different sw packages is acceptable in only a minority of cases, and doesn't seem to be the case here.
danpalmer 2y ago
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.
- rationably 2y ago
  Could you provide an example where maintainer "ripped out" a feature because of a strictly political reason?
  - danpalmer 2y ago
    When I say "political" I'm referring more to belief systems, but calling them religious beliefs would be far too antagonistic for the point I'm trying to make. Iceweasel is full of examples of parts of Firefox removed because the maintainers had personal disagreements on the values of Firefox. Firefox is a fairly privacy-forward browser and Mozilla stand up for a lot of those ideals, and yet Iceweasel pulls features and telemetry on the basis of them being by-definition bad. I think that's a politics/identity statement more than a UX improvement. I strongly disagree with packagers putting their opinion on top of the software they are packaging, I think packaging should be as pure a translation as is possible for the target system. Now in the case of Iceweasel it could change the branding which I think would give them more leeway to put opinion into it as it's "not Firefox" and there's little risk of users being confused, but I'd also bet that Debian wouldn't accept another pure Firefox packaging because it would duplicate the package in their minds. If that is the case I think that nullifies the idea.
bananenpubs 2y ago
[dead]
juliangmp 2y ago
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
egberts1 2y ago
Should bave left the original KeyPassXC Debian package alone and ... Instead to create a `keypassxc-offline` package with those tweaks.
FergusonMiriam 2y ago
[dead]
Zuiii 2y ago
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.
willywanker 2y ago
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.
- kasabali 2y ago
  That's a very misleading comparison. When Mozilla (upstream) axes a feature, it's gone permanently and you can't get it back. Which is not the case here at all, here downstream turns off a feature in the default build, while simultaneously providing the fully featured version in a just as easily installable package.

312 points by CuriousIndian 2y ago

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.

bananapub 2y ago
not sure why you're commenting without even reading the linked 200 character post? the maintainer has enabled all plugins (including network stuff) in the keepassxc-full package, the keepassxc package will be just the basics with a much better security posture. that's obviously completely fine and completely within the remit of a maintainer, the entire complaint is about this being a change.
- milliams 2y ago
  As stated in the GitHub thread [1]: You fundamentally misunderstand our program when you use the word plugin. These are built in features, not plugins. The features can be enabled as desired by the user and they come disabled by default. This change to not compile and ship these features in the base keepassxc package does nothing besides create angry (or confused) users. [1] https://github.com/keepassxreboot/keepassxc/issues/10725#issuecomment-2104508951 https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
  - bananapub 2y ago
    that seems completely irrelevant? plugin, compile time ./configure flag, whatever - package maintainers extremely routinely create multiple versions of a package for various reasons, from security (this case) to dependencies (Debian contains a emacs-nox package that is emacs compiled without X libraries to avoid dragging them in on servers, for example) to license reasons. again, all of the complaints are literally about the change, which the maintainer has decided to do in a disruptive fashion.
  - arp242 2y ago
    That Canonical guy is not coming off brilliantly there. I appreciate that reasonable people can disagree on the best way to package this, but these kind of strong absolute statements – together with calling useful features "misguided" and "crap" – is not great, to put it mildly. I'm pretty sure some compromise could theoretically be reached here. But not with that attitude. "It is our responsibility to our users to provide them the most secure option possible as the default"? You know what would be even more secure? To disable all networking in any program, and in fact, in Linux itself. Actually, it's even more secure to just not give people a computer at all. This is one of those stupid discussion-stoppers. These kind of Highly Opinionated Maintainers™ has always been what put me off from Debian (and by extension, Ubuntu). I want to use KeePassXC, not "KeePassXC as some random guy thinks it should have been".
    - trallnag 2y ago
      What's the alternative to Debian / Ubuntu now that CentOS is gone?
      - lawn 2y ago
        Arch Linux and Void Linux are both worth a look I'd say.
        TheBicPen 2y ago
        I believe the zoomer response to this is "bruh"
        yjftsjthsd-h 2y ago
        Rolling-release distros are unlikely to fit into the same usecase as a slow-moving stable-release distro.
      - arp242 2y ago
        AlmaLinux and Rocky Linux are continuations of CentOS; I have no experience with either but that would be the logical place to start.
      - 2y ago
- jdbernard 2y ago
  The problem is that this will break all existing users who use those features when they update. One of the comments in the GitHub thread has a better path, IMHO: ship two new packages, a -minimal and a -full, and the user to choose, rather than silently break functionality (NEWS is fine, but not really read by user as everyone admits).
- JohnTHaller 2y ago
  The default package should be named keepassxc-debian-limited or similar and the proper package should be keepassxc
  - bananapub 2y ago
    OK? that has nothing to do with what I was correcting: > 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. the downstream maintainer didn't "change a package in a way that doesn't have the intent of the upstream project", they altered the config flags in one package and made another with the previous flags. the maintainer is being a dick, but not in the way the OP suggested.
    - Dylan16807 2y ago
      > the downstream maintainer didn't "change a package in a way that doesn't have the intent of the upstream project", they altered the config flags in one package and made another with the previous flags. They altered the config flags in a way that doesn't have the intent of the upstream project. And I would classify build config changes as a subset of "changing a package".
  - Dah00n 2y ago
    Use JohnTHallerNix and it can be. Debian is again taking care of their users. Unlike upstream, Which isn't new. Did he do it in the best way? No. Did he do the right thing? Absolutely.
  - hi-v-rocknroll 2y ago
    It's the tyranny inherent to dependency-hell monolithic package management. nix avoids this problem by permitting multiple versions and flexible configurations of the same package.
- nulld3v 2y ago
  But that's not what they disagree with. They are saying you shouldn't have a package called "keepassxc" if it is missing a ton of features from upstream KeepassXC. You should name it something different instead. So you shouldn't have "keepassxc" and "keepassxc-full". Instead you should have "keepassxc" and "keepassxc-minimal".
  - vlovich123 2y ago
    But it’s a valid build configuration option provided by upstream. Not sure I follow this line of reasoning.
    - nulld3v 2y ago
      Sure, I think that's a reasonable stance. If upstream agrees that such a configuration is a valid distribution of KeepassXC and can be branded KeepassXC, then that's up to them. I would probably disagree with upstream in that scenario just from a UX perspective, but I would understand both sides. But in this case, upstream has responded and clearly indicated that they do not want the minimal distribution of KeepassXC to be branded as the main "keepassxc" package: https://github.com/keepassxreboot/keepassxc/issues/10725#issuecomment-2104381335 https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
- WesolyKubeczek 2y ago
  Because I run and upgrade and suddenly all my shit stops working without warning, that's why. It's not how things should be done.
donio 2y ago
The WITH_XC_NETWORKING build option is off by default so the developers have obviously intended this to be a valid build configuration.
- fallingsquirrel 2y ago
  Sure, but that doesn't change the fact that a point release suddenly broke everyone's workflows and is causing maintenance headaches. I don't think the technical minutia of how exactly things were broken is the issue. If Debian shipped a Linux kernel point release that disabled networking I think people would be similarly upset, even though it's also just a build option and intended to be a valid build configuration (and would even more secure!)
  - Dah00n 2y ago
    >If Debian shipped a Linux kernel point release that disabled networking That is not comparable. "If Debian shipped a Linux kernel point release that removed a risky networking plugin and some disabled-by-default plugins and made a -full version" that would be comparable.
    - MatthiasPortzel 2y ago
      It’s exactly comparable. The browser-autofill functionality in KeyPassXC is not a plug-in and it’s not risky. The person saying that is the Debian maintainer.
    - nulld3v 2y ago
      Hmm, excluding the comment about the missing "-full" version, I don't see how it is not comparable. There is nothing that makes the networking code in KeepassXC more "risky" compared to the networking code in Linux.
  - kasabali 2y ago
    > that doesn't change the fact that a point release suddenly broke everyone's workflows BS. This change was in Debian sid/testing. That's what it's for. Debian stable users' workflow hasn't been broken.
JohnTHaller 2y ago
Either that or it should indicate to the end user that it's an unsupported package. Maybe showing up as KeePassXC-Debian or KeePassXC-Unsupported and have the developer's contact details (website etc) removed from About and replaced with the Debian details for support. A downstream maintainer making small changes to fit within the OS that doesn't meaningfully affect the app is fine. A downstream maintainer modifying an app and removing core functionality so the upstream dev gets a ton of grief is not.
- deleted 2y ago
  [deleted]
yencabulator 2y ago
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) https://github.com/keepassxreboot/keepassxc/blob/develop/INSTALL.md https://github.com/keepassxreboot/keepassxc/blob/develop/INS...
yjftsjthsd-h 2y ago
> and that maintainer deal with all bug reports caused by their modified version. I appreciate that it often doesn't happen, but that's supposed to be the default flow regardless: If you're using a distro-provided package and hit a bug, you're supposed to open a bug report against the distro package, and then the maintainer looks at it, and if the bug came from upstream then they file a bug with the upstream project. This is helpful because 1. the package maintainer is probably familiar with the package and can provide initial triage/analysis, possibly even being able to fix the bug outright before going upstream to share the fix, and 2. as you note, distro packages frequently carry some amount of patching and the maintainer should verify whether the bug is in their packaging or the upstream source code. Unfortunately, many users default to reporting upstream first:( So in practice this is a concern, but it's really not supposed to be.

HieronymusBosch 2y ago

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

okl 2y ago
Debian maintainer, Julian Klode, has a "pointed" opinion: > 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.
- lupusreal 2y ago
  [flagged]
  - nulld3v 2y ago
    They removed other non-networking features too. E.g. even autotype was removed. At that point why not just store your passwords in an encrypted notes app?
    - zikduruqe 2y ago
      Just use https://www.passwordstore.org https://www.passwordstore.org
    - lupusreal 2y ago
      I use KeePassXC, but not any network features or autotyping, because I like the password generation and because the interface is nice. I previously used Vim's old encryption feature (since removed I think?) and I think KeePassXC as I use it is a good upgrade from that.

derkades 2y ago

Good discussion here: https://github.com/keepassxreboot/keepassxc/issues/10725 https://github.com/keepassxreboot/keepassxc/issues/10725

rurban 2y ago

[flagged]

jdbernard 2y ago
The most secure system is the system with no features! Let's delete everything. #nofeatures #securityonly
- doubled112 2y ago
  Guess this is it. I'm powering everything down for security reasons. To the woods I go to build a cabin.
  - Takennickname 2y ago
    They made a netflix documentary about the last guy who did that. He wrote a pretty good manifesto.
- rurban 2y ago
  Nothing is deleted. Just the default options are now used, as intended and announced upstream. How should a debian openssh be called, with custom patches to integrate systemd logging, enabling all old and insecure cyphers? Or a debian openssl with all legacy cyphers enabled?
  - nulld3v 2y ago
    > as intended and announced upstream Meanwhile, from a maintainer of the KeepassXC repo: > Good luck to you. Really bad decision. We will be sure to let everyone know. https://github.com/keepassxreboot/keepassxc/issues/10725#issuecomment-2104430596 https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
- Brian_K_White 2y ago
  [flagged]

theamk 2y ago

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#issuecomment-2104401817 https://github.com/keepassxreboot/keepassxc/issues/10725#iss... [1] https://github.com/keepassxreboot/keepassxc/issues/10725#issuecomment-2104512907 https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

Arnavion 2y ago
There's one way in which browser integration improves security vs not using it, which is that the browser extension checks the page URL before filling in the credentials, while the approach of manually copy-pasting credentials is vulnerable to typo- and homoglyph-phishing.
- JeremyNT 2y ago
  This is essential to my own usage of KeepassXC. I never copy/paste from it into a browser and appreciate having this first line defense against phishing.
- tuetuopay 2y ago
  This. So much this. I don't even understand how browser integrations are not universally thought as a core part of a password manager. With all the phishing that's going along, it's really the last line of defense. Oh and I'm not only talking about elderly relatives and such. Modern phishings are very very well made, and there's one going on to steal Steam accounts that I would have likely fell for (and I consider myself pretty good on the matter).

chomp 2y ago

Seems like a positive change to me.

brnt 2y ago
They disabled all plugins, not just those that may access networks. This is not good, it's nonsensical.
- Brian_K_White 2y ago
  Thinking browser or other local integration is not as dangerous as network features is nonsensical. All of the disabled features are expendable. I never used any even while they were in there. Yet I do use keepassxc all day every day for the one job it actually does exist to do. Convenience and necessity are two different things. You want conveninece, and you're not wrong to want it, but you don't need it, and your want of convenience is not important enough to make the base utility when it is a password manager and not a gif editor less safe than it could be by default. It is correct that if you want to trade away safety for convenience, that you have to go out of your way to add that yourself, even if most people will choose to do that, and even if the previous default was backwards and it's now ever so slightly disruptive to correct that error now.
  - timw4mail 2y ago
    Absolute security means you can't do anything. Too much security friction can easily lead to *much more insecure* workarounds.
    - Brian_K_White 2y ago
      Somehow, I have been using the same app without any of those features. So, the idea that the app is not functional or useful without them is bullshit. As for friction leading indirectly to less security through user behavior... how many clicks and how many seconds is it to install the full version? So, yet more bullshit.

alyandon 2y ago

Gutting the functionality that upstream has built into a piece of software and then publishing it under the same name is dubious at best. If they want to go this direction they should publish as a fork under a different name so upstream doesn't get constantly barraged by complaints of users having issues. 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.

Dah00n 2y ago
They didn't "gut what upstream built". He published it without plugins and made a -full version that include plugins. If plugins are plugged in as default it isn't a plugin but a built-in feature. This is the correct way.
- tdb7893 2y ago
  Default plugins is a very common pattern and often what users want. There can be technical reasons but also for common features it's way to have them as opt-out instead of 99% of people needing to opt-in to the same stuff
- bananenpubs 2y ago
  He published it w/o core package functionality. There are no plugins with KXC, that is one of their main arguments: don't rely on 3rd party code, bring it all inhouse, where it can be checked / maintained.
  - redeeman 2y ago
    as others said, core functionality that UPSTREAM THEMSELVES decided not to include in default/recommended build instructions?
    - 2y ago

2OEH8eoCRo0 2y ago

It sounds like a necessary but painful change if we want secure by default.

bananenpubs 2y ago
Speak for yourself, please, not for 'us'.
- guilhas 2y ago
  [flagged]

unparagoned 2y ago

People always crap over LastPass, but when you ask them what they do, it’s some elaborate process relying on thousands of no name packages and devs.

lawn 2y ago

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.

wswope 2y ago
> a couple of years ago You’re bearing a grudge based on an unintentional bug introduced 18 years ago. Weak take and irrelevant to topic at hand.

charles_f 2y ago

> 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.

Brian_K_White 2y ago
[flagged]

rfoo 2y ago

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.

jeffalyanak 2y ago

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#issuecomment-2104845637 https://github.com/keepassxreboot/keepassxc/issues/10725#iss... Why would this _not_ be the obvious choice?

rfoo 2y ago
Because maintainers have an opinion and explicitly wanted to change the default.
- jeffalyanak 2y ago
  That does allow you to change the default for users installing the packages and while ensuring that users who already have it installed don't lose functionality during an upgrade.
- GorsyGentle 2y ago
  Perhaps, and that's not unreasonable in and of itself. But to do so in such a user-hostile manner? That's a bit over the top. A new minimal package, advertising it, and only then eventually making it the default would have been far, far more effective. If an engineer of mine pulled this on our user-base I'd have them reverting it in a heartbeat regardless of the technical merit. They already failed just in how they executed this and have burned good will, the technical merits no longer matter. Once you've lost the faith and trust of the user, it's over. The original request[0] was more or less simply a user asking for the networking to be removed, and follow-up to just have a -nonetwork variation. Instead, we have comments from the debian maintainer: The OP report: > Users who need this crap can install the crappy version but obviously this increases the risk of drive-by contributor attacks. The debian package description[1]: > See keepassxc-full if you absolutely need those. The PR[2] > Feature creep like SSH agent support, browser integration, Freedesktop.org secret storage, KeeShare pose undue risks for most users. Each one of these sends a message. And it was entirely avoidable with a bit of grace and kindness to the existing userbase. [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529 [1]: https://packages.debian.org/sid/keepassxc https://packages.debian.org/sid/keepassxc [2]: https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f8de487b12266a1cb7975e2b7df2e3a4#b3f55b8d9783f2ed27acfd1f0fe06dfc461e2aba_0_4 https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f...

Brian_K_White 2y 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.

kernal 2y ago
A password manager with a built-in MP3 player? That's my next project.
- Brian_K_White 2y ago
  The songs could tell you where to find the post-it note within your record library. Let the hackers gain access to your google drive AND decrypt the db. :)
Latty 2y ago
Safest by what metric? Calling the browser integration a "convenience" feature only is just fundamentally wrong. Realistically the most common attack most users face is a phishing attack, removing the browser integration which checks the URL programmatically before filling the password opens the user up to being phished more easily (users check URLs less consistently and less reliably), so arguably this makes the package less secure in the real world.
Spivak 2y ago
Debian is somewhat inconsistent with this but it does have precedent for package to be package-minimal and a corresponding full- variant. Odd to just break users by doing this, should have been done with a major release when people expect breakage.
- 2y ago

jchw 2y ago

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.

kernal 2y ago

I like this solution. He reduced the attack vectors in the base application by removing features a large majority of people don't use. And if they want these additional features then download the full version.

nulld3v 2y ago
> features a large majority of people don't use. I would be shocked if this was true. I have recommended KeepassXC to many of my friends and family and they all use at least one of the features that was in the removed list. To be fair, none of them use debian, but some of them do use other Linux distros. I don't use debian on desktop anymore on my main machine, but I did use BunsenLabs for a long time and even back then KeepassX (and afterwards KeepassXC) auto-type was a critical feature I used literally every day.
- gr4vityWall 2y ago
  I never knew KeepPassXC could talk with my browser or interact with ssh until I saw this thread, and I've been using it for almost 10 years now.

coppsilgold 2y ago

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 https://github.com/containers/bubblewrap> [2] <https://git.sr.ht/~whynothugo/way-secure https://git.sr.ht/~whynothugo/way-secure>

Kwpolska 2y ago

[flagged]

0x_rs 2y ago

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.

DDiggler 2y ago

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 https://github.com/fwupd/fwupd/issues/6721 [2]: https://news.ycombinator.com/item?id=7347500 https://news.ycombinator.com/item?id=7347500 [3]: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=gnutls https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=gnutls

workethics 2y ago
Good to know. I think this should probably be it's own post
- 1oooqooq 2y ago
  https://news.ycombinator.com/item?id=40322408 https://news.ycombinator.com/item?id=40322408
1oooqooq 2y ago
why fish for fwupd? systemd-resolved which is everywhere, will open (at request) an LLMNR server (a.k.a. mDNS, nee microsoft netbios) on port 5355. With IoT everyone have access to your LAN, so now people are making sure linux also join the REDACTED party btw, fix for fwupmdg, since they have a low quality default conf file without commented out defaults: ``` # /etc/fwupd/fwupd.conf [fwupd] P2pPolicy=none ``` fix for resolved is commented out on /etc/systemd/resolved.conf `LLMNR=no`, and you probably also want `DNSStubListener=no`. heck here is a good default ``` # /etc/systemd/resolved.conf [Resolve] DNS=9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net FallbackDNS=127.0.0.1 ::1 Domains=~. DNSOverTLS=yes LLMNR=no DNSStubListener=no ```
- 2y ago

tuetuopay 2y ago

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

cyanydeez 2y ago
This reminds me of the how to secure a trashcan from bears in yellow stone: the dumbest person and the smartest bear has significant overlap. Protecting a few dumb people means exposing a lot more people to attack vectors.

lawn 2y ago

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#issuecomment-2105085740 https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

guilhas 2y ago
Everyone using an offline password manager without having a backup might as well consider everything lost This sounds like emotional blackmail How many times I lost everything, hardware failure, updates that broke OS, using dd in the wrong drive...
- valicord 2y ago
  How would a backup help in this scenario? The data is fine, it's the application that stopped working.
  - guilhas 2y ago
    If the yubikey stops working, you also loose access to the database So I would have a backup with a simple password, or even unencrypted in a USB somewhere
    - valicord 2y ago
      You backup the yubikey seed (whatever it's called) separately from the password db, so that the attacker still has to get 3 separate pieces of information (db, password, seed) to get the full access.
      - guilhas 2y ago
        If you backup the "seed" hotp secret you can probably use any OTP client software to open the DB without needing the yubikey

TheChaplain 2y ago

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.

SAI_Peregrinus 2y ago
They made the default the stripped-down one, which removes security features like the anti-phishing prevention in the browser extension.

shmerl 2y ago

There was some comment about it. Basically, it's for security reasons. Those who aren't using those features wouldn't expect them to appear (especially sneakily). And those who are planning to use them will figure out what package to install. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529 This was the message from maintainers: Networking and all plugins have been moved into the keepassxc-full package. Feature creep like SSH agent support, browser integration, Freedesktop.org secret storage, KeeShare pose undue risks for most users.

Dylan16807 2y ago
Browser integration and autotype are not feature creep. Making everything copy-paste is bad for security.

nsajko 2y ago

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".

gradientsrneat 2y ago
Said maintainer also does dev work for Canonical. So this probably affects optics for Ubuntu too. Although, speculating charitably, maybe the maintainer knows something we don't about the upstream's security policies.
FdbkHb 2y ago
Debian maintainers are experts at touching things they shouldn't and creating a mess in the process. The worst case, by far, was when they broke the RNG of SSH key generation: https://jblevins.org/log/ssh-vulnkey#:~:text=In%20May%202008%2C%20a%20bug,systems%20should%20be%20considered%20compromised https://jblevins.org/log/ssh-vulnkey#:~:text=In%20May%202008.... Those guys are out of control and constantly having conflicts with upstream, I'm astounded to see the amount of support I see for debian in this thread.

cookiengineer 2y ago

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529 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.

vbezhenar 2y ago

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.

gr4vityWall 2y ago

The maintainer's position seems reasonable to me. A different package, compiled with the network features, is provided too. I like this as a default.

xcdzvyn 2y ago

Fortunately Debian maintainers have a fantastic track record of writing ad-hoc patches for security-sensitive software.

hi-v-rocknroll 2y ago

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).

hiAndrewQuinn 2y ago
I recently switched from BW to XC in the wake of their acquisition, and I have to admit, the mobile experience is just a little more annoying. But I sleep better at night knowing that I don't keep anything critical on servers I don't own.
- hi-v-rocknroll 2y ago
  1. What acquisition? https://bitwarden.com/blog/ https://bitwarden.com/blog/ 2. You can run your own FOSS Bitwarden sync server. It even works airgapped. https://bitwarden.com/help/install-and-deploy-offline/ https://bitwarden.com/help/install-and-deploy-offline/

yawaramin 2y ago

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.

parasti 2y ago

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.

YPPH 2y ago
>power maintainers hold over someone else's software There's some subtle assumptions about ownership in this comment that aren't accurate, insofar as free and open source software is concerned. FOSS software is not "someone else's" software. They may own the trade mark, but by releasing the software under a FOSS licence, they lose the right to control the direction the software may take. I'm free to copy it, edit it, and redistribute it as I see fit. So are you. So is Debian.
- parasti 2y ago
  That's besides the point. You can do whatever with the software, but it gets muddy when you then release it under the same name as the original. That name may not be trademarked, but it is still not yours to use.
  - deleted 2y ago
    [deleted]
  - YPPH 2y ago
    This simply is irrelevant. A FOSS licence fully permits what Debian has done here. So, that is beside the point.
kasabali 2y ago
Not even comparable. Debian users can choose between the stripped and full version of Keepassxc, unlike the MESA example above.

raverbashing 2y ago

Hissy-fits like these are one of the reasons there's never going to be a "year of the linux on desktop" But why do they care, right? Most people on their irc channel (that have a basement NAS may I add) agree with their decision. Now my bet is that your average Debian user does care about convenience. Replacing (default off) selection boxes with different sw packages is acceptable in only a minority of cases, and doesn't seem to be the case here.

danpalmer 2y ago

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.

rationably 2y ago
Could you provide an example where maintainer "ripped out" a feature because of a strictly political reason?
- danpalmer 2y ago
  When I say "political" I'm referring more to belief systems, but calling them religious beliefs would be far too antagonistic for the point I'm trying to make. Iceweasel is full of examples of parts of Firefox removed because the maintainers had personal disagreements on the values of Firefox. Firefox is a fairly privacy-forward browser and Mozilla stand up for a lot of those ideals, and yet Iceweasel pulls features and telemetry on the basis of them being by-definition bad. I think that's a politics/identity statement more than a UX improvement. I strongly disagree with packagers putting their opinion on top of the software they are packaging, I think packaging should be as pure a translation as is possible for the target system. Now in the case of Iceweasel it could change the branding which I think would give them more leeway to put opinion into it as it's "not Firefox" and there's little risk of users being confused, but I'd also bet that Debian wouldn't accept another pure Firefox packaging because it would duplicate the package in their minds. If that is the case I think that nullifies the idea.

bananenpubs 2y ago

[dead]

juliangmp 2y ago

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

egberts1 2y ago

Should bave left the original KeyPassXC Debian package alone and ... Instead to create a `keypassxc-offline` package with those tweaks.

FergusonMiriam 2y ago

[dead]

Zuiii 2y ago

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.

willywanker 2y ago

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.

kasabali 2y ago
That's a very misleading comparison. When Mozilla (upstream) axes a feature, it's gone permanently and you can't get it back. Which is not the case here at all, here downstream turns off a feature in the default build, while simultaneously providing the fully featured version in a just as easily installable package.