8 ms·

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 diffe

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.

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.