7 ms·

If both upstream and a significant portion of users strongly disagree with a maintainer's judgement, then how is their role as maintainer justified? It's KeePa

If both upstream and a significant portion of users strongly disagree with a maintainer's judgement, then how is their role as maintainer justified? It's KeePassXC's job to secure the software and produce features that fulfill users' needs as they see fit. Julian's role as maintainer may intersect with that to a limited extent, in deciding on what kind of defaults best fit the rest of the OS. But, in this case, the developers of the software disagree with his justifications, and reasonable users are also disagreeing with the change. It seems clear Julian wandered outside his role a bit here.

cjk2 2y ago
I think you'd have to actually ask the users about that. Not make assumptions based on some loud people on a Mastodon thread. What the user is given here is a choice.
- petee 2y ago
  But they already had a choice, since the removed options were disabled by default. This really just breaks core functionality that exists and is expected by real users, under the guise of unnamed security risks...theres plenty of disabled options in Linux that are "potential" risks, so its a silly choice.
  - cjk2 2y ago
    Hyperbole! $ apt install keepassx $ apt install keepassx-full Choice made.
    - petee 2y ago
      Choice was already made when they installed it with xyz features available. If it was so important they never should have packaged it in the first place. -Minimal option is the obvious reasonable choice, unless trying to be an arse to make a point, since you're changing a users choice after the fact. Are we going to stop compiling sshd with plaintext pw options and root login, and suddenly? If a user has an option enabled you don't like anymore, notify them, don't blindly remove functionality and say "your fault for not reading the changelogs". Frankly the security claims ring more of hyperbole than anything
      - kasabali 2y ago
        > If a user has an option enabled you don't like anymore, notify them, don't blindly remove functionality and say "your fault for not reading the changelogs". apt shows the NEWS file during update when there's a change. These users not only have chosen to actively ignore the warning that has been shown to them by default, they've also chosen to directly go to upstream to complain instead of first their distributions channels.
    - jdbernard 2y ago
      Let's say that I had the previous version of keepassxc installed and used a Yubikey to protect it. Now when the distro updates, through no actions of my own, I will be locked out of my password DB because the Yubikey extension is no longer compiled in to the version of KeePassXC the distro is shipping under the original name. Yes, this breaks core functionality. How is this a good thing?
- worble 2y ago
  Well no, what the user is actually being given is a completely different application than the original one they downloaded, which is now increasing the maintenance burden upstream because THEY are they one getting all the bug reports because Debian decided to swap the packages out from underneath their users: https://github.com/keepassxreboot/keepassxc/issues/10725#issuecomment-2104381335 https://github.com/keepassxreboot/keepassxc/issues/10725#iss... > This is now our fourth bug report because of the decision to neuter the base KeePassXC package in Debian
  - cjk2 2y ago
    It's not completely different. They patched stuff out. And I, as an end user, am absolutely fine with that, as a user of vim-nox package etc etc...
    - riedel 2y ago
      I thought from reading the bug report is that they only changed the default of a supported cmake build flag. I think that a keepass-nonet would have be a wiser choice, but I do not blame Debian people to be opinionated towards the more secure choice.
    - alyandon 2y ago
      vim-nox is pretty much full-featured vim without x11 stuff. Do you have a non-trivial .vimrc/.vim directory? Would you be accepting of the maintainer disabling a bunch of features and pushing those changes out under the main vim-nox package such that it breaks your existing install? Would it be reasonable to expect you as the end user to figure out what has happened and that you need to uninstall vim-nox and and install vim-nox-full?
      - cjk2 2y ago
        My .vimrc is 8 lines. I learned not take the kitchen sink with me on holiday.
    - yjftsjthsd-h 2y ago
      But vim-nox is a separate package with a clear name saying that it's got X removed; I don't think this would be nearly as controversial if they'd shipped a keepassxc-nonetwork package.
- thaumaturgy 2y ago
  Users should be asked if they actually wanted the features in the existing package after all? Why shouldn't users have been asked before changing the existing package? I'm one of those users. If I'm loud, does that mean my opinion doesn't count anymore?
  - pessimizer 2y ago
    It never counted. You can suggest or advise, but you never had the power to tell Debian what to do. Being loud will not change that, no. You'll have to resort to persuasion.
  - kasabali 2y ago
    > Why shouldn't users have been asked before changing the existing package? They were. apt shows the NEWS file during update when there's a change.
    - Kwpolska 2y ago
      I don't recall ever seeing that on Debian and derivatives.
      - kasabali 2y ago
        I can only talk for Debian, not derivatives. You definitely see it for several packages during dist-upgrades. Same in sid/testing except it can be any time though it's a rare event. In case apt/dpkg is configured to ignore those, information still resides in /usr/share/doc/<pkg> it'll also be put in the release notes when the next major Debian version is released. I mean, distributions have already figured these things out 20 years ago, but I guess users nowadays expect these to be announced in Twitter or a pinned Github issue or something :-<
      - LightFog 2y ago
        Me neither in Sid - I guess they installed the listchanges package some time and forgot.
barbariangrunge 2y ago
Sorry, why do maintainers owe us anything? They’re typically unpaid or poorly paid and are doing everyone a favour. The code is open source and anyone who doesn’t like their work can easily fork the project. They don’t need to justify anything to us
- Kwpolska 2y ago
  This isn’t the project maintainer we’re talking about, it’s the Debian package maintainer. Their job is building a working .deb with working software, not randomly messing with it. Users have the right to demand their packages to be trustworthy.
  - g1sm 2y ago
    He wasn’t randomly messing with it, there was a bug report about this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529
    - Kwpolska 2y ago
      Doing it in response to a single user’s bug report from 2020 that does not provide any rationale other than “network access bad” constitutes randomly messing with packages.
      - WorldMaker 2y ago
        You doubt that bug poster's "belief" that "most people want" that change?
      - whoopdedo 2y ago
        The feature flag is put there by upstream. If they don't want to support non-network installs then why do they even have that lever? That said it probably makes more sense for Debian to package a `keepassxc-nonet` alongside the default `keepassxc` so end users can choose the variant.
pessimizer 2y ago
> If both upstream and a significant portion of users strongly disagree with a maintainer's judgement, then how is their role as maintainer justified? By their making the decision they think is best and that agrees with the philosophy of the distribution they're maintaining the package for? I'm glad they don't have to justify their existences to upstream and every "significant portion[...] of users." > It's KeePassXC's job to secure the software and produce features that fulfill users' needs as they see fit. You don't control free software after you've licensed and distributed it that way. The entire point of the concept is to make calls like this about anti-features. KeePassXC can feel free to comment on it, like anyone else. They can demand that Debian make available the modified sources. They can revoke any license to the use of trademarks. That's it. If users only want to deal with KeePassXC, they can compile it themselves or use a portable version. If KeePassXC wants to deal with Debian users directly, they can host a package repository for their canonical version.
makeitdouble 2y ago
> KeePassXC's job Is KeepassXC even a company ? looking at their site and wikipedia, they're just a bunch of people dedicated enough to maintain the project. Looking at the donation page [0] they don't even list anything going to themselves in the use of the money. So they're effectively paying with their time to keep the thing alive. If anything the community seem to own a ton to these guys. [0] https://keepassxc.org/donate/ https://keepassxc.org/donate/
- omoikane 2y ago
  This reminds me of "The gift of it's your problem now" (2021): The best part of free software is it sometimes produces stuff you never would have been willing to pay to develop (Linux), and sometimes at quality levels too high to be rational for the market to provide (sqlite). The worst part of free software is you get what you get, and the developers don't have to listen to you. (And as a developer, the gift recipients aren't always so grateful either.) https://apenwarr.ca/log/20211229 https://apenwarr.ca/log/20211229 https://news.ycombinator.com/item?id=29736369 https://news.ycombinator.com/item?id=29736369
HumanProtractor 2y ago
Upstream's irrelevant to a maintainer. Downstream? Maintainers typically know best, that's why the user chose that distro. I bailed on Debian when they decided to go systemd. That's Democracy.
m-p-3 2y ago
The default build of KeepassXC is without any optional modules https://github.com/keepassxreboot/keepassxc/wiki/Building-KeePassXC#build-options https://github.com/keepassxreboot/keepassxc/wiki/Building-Ke... -DWITH_XC_ALL=[ON|OFF] Enable/Disable compiling all plugins above (default: OFF) To me, it seems like the maintainer is simply bringing the default package back to what it should have been, and he's offering another build with all features enabled under keepassxc-full If KeepassXC is unhappy with the defaults, they can adjust theirs to reflect what they feel should be available out of the box.
scovetta 2y ago
Obligatory article, "I am not a supplier.": <https://www.softwaremaxims.com/blog/not-a-supplier https://www.softwaremaxims.com/blog/not-a-supplier> Folks that disagree with a maintainer's actions are generally free to fork the project and maintain an alternative -- that's one of the primary features of open source software. And if end users prefer that new fork to the original maintainer's version, that'll probably be the one that survives. But maintainers have no obligation to make their end users happy.

cjk2 2y ago

I think you'd have to actually ask the users about that. Not make assumptions based on some loud people on a Mastodon thread. What the user is given here is a choice.

petee 2y ago
But they already had a choice, since the removed options were disabled by default. This really just breaks core functionality that exists and is expected by real users, under the guise of unnamed security risks...theres plenty of disabled options in Linux that are "potential" risks, so its a silly choice.
- cjk2 2y ago
  Hyperbole! $ apt install keepassx $ apt install keepassx-full Choice made.
  - petee 2y ago
    Choice was already made when they installed it with xyz features available. If it was so important they never should have packaged it in the first place. -Minimal option is the obvious reasonable choice, unless trying to be an arse to make a point, since you're changing a users choice after the fact. Are we going to stop compiling sshd with plaintext pw options and root login, and suddenly? If a user has an option enabled you don't like anymore, notify them, don't blindly remove functionality and say "your fault for not reading the changelogs". Frankly the security claims ring more of hyperbole than anything
    - kasabali 2y ago
      > If a user has an option enabled you don't like anymore, notify them, don't blindly remove functionality and say "your fault for not reading the changelogs". apt shows the NEWS file during update when there's a change. These users not only have chosen to actively ignore the warning that has been shown to them by default, they've also chosen to directly go to upstream to complain instead of first their distributions channels.
  - jdbernard 2y ago
    Let's say that I had the previous version of keepassxc installed and used a Yubikey to protect it. Now when the distro updates, through no actions of my own, I will be locked out of my password DB because the Yubikey extension is no longer compiled in to the version of KeePassXC the distro is shipping under the original name. Yes, this breaks core functionality. How is this a good thing?
worble 2y ago
Well no, what the user is actually being given is a completely different application than the original one they downloaded, which is now increasing the maintenance burden upstream because THEY are they one getting all the bug reports because Debian decided to swap the packages out from underneath their users: https://github.com/keepassxreboot/keepassxc/issues/10725#issuecomment-2104381335 https://github.com/keepassxreboot/keepassxc/issues/10725#iss... > This is now our fourth bug report because of the decision to neuter the base KeePassXC package in Debian
- cjk2 2y ago
  It's not completely different. They patched stuff out. And I, as an end user, am absolutely fine with that, as a user of vim-nox package etc etc...
  - riedel 2y ago
    I thought from reading the bug report is that they only changed the default of a supported cmake build flag. I think that a keepass-nonet would have be a wiser choice, but I do not blame Debian people to be opinionated towards the more secure choice.
  - alyandon 2y ago
    vim-nox is pretty much full-featured vim without x11 stuff. Do you have a non-trivial .vimrc/.vim directory? Would you be accepting of the maintainer disabling a bunch of features and pushing those changes out under the main vim-nox package such that it breaks your existing install? Would it be reasonable to expect you as the end user to figure out what has happened and that you need to uninstall vim-nox and and install vim-nox-full?
    - cjk2 2y ago
      My .vimrc is 8 lines. I learned not take the kitchen sink with me on holiday.
  - yjftsjthsd-h 2y ago
    But vim-nox is a separate package with a clear name saying that it's got X removed; I don't think this would be nearly as controversial if they'd shipped a keepassxc-nonetwork package.
thaumaturgy 2y ago
Users should be asked if they actually wanted the features in the existing package after all? Why shouldn't users have been asked before changing the existing package? I'm one of those users. If I'm loud, does that mean my opinion doesn't count anymore?
- pessimizer 2y ago
  It never counted. You can suggest or advise, but you never had the power to tell Debian what to do. Being loud will not change that, no. You'll have to resort to persuasion.
- kasabali 2y ago
  > Why shouldn't users have been asked before changing the existing package? They were. apt shows the NEWS file during update when there's a change.
  - Kwpolska 2y ago
    I don't recall ever seeing that on Debian and derivatives.
    - kasabali 2y ago
      I can only talk for Debian, not derivatives. You definitely see it for several packages during dist-upgrades. Same in sid/testing except it can be any time though it's a rare event. In case apt/dpkg is configured to ignore those, information still resides in /usr/share/doc/<pkg> it'll also be put in the release notes when the next major Debian version is released. I mean, distributions have already figured these things out 20 years ago, but I guess users nowadays expect these to be announced in Twitter or a pinned Github issue or something :-<
    - LightFog 2y ago
      Me neither in Sid - I guess they installed the listchanges package some time and forgot.

barbariangrunge 2y ago

Sorry, why do maintainers owe us anything? They’re typically unpaid or poorly paid and are doing everyone a favour. The code is open source and anyone who doesn’t like their work can easily fork the project. They don’t need to justify anything to us

Kwpolska 2y ago
This isn’t the project maintainer we’re talking about, it’s the Debian package maintainer. Their job is building a working .deb with working software, not randomly messing with it. Users have the right to demand their packages to be trustworthy.
- g1sm 2y ago
  He wasn’t randomly messing with it, there was a bug report about this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529
  - Kwpolska 2y ago
    Doing it in response to a single user’s bug report from 2020 that does not provide any rationale other than “network access bad” constitutes randomly messing with packages.
    - WorldMaker 2y ago
      You doubt that bug poster's "belief" that "most people want" that change?
    - whoopdedo 2y ago
      The feature flag is put there by upstream. If they don't want to support non-network installs then why do they even have that lever? That said it probably makes more sense for Debian to package a `keepassxc-nonet` alongside the default `keepassxc` so end users can choose the variant.

pessimizer 2y ago

> If both upstream and a significant portion of users strongly disagree with a maintainer's judgement, then how is their role as maintainer justified? By their making the decision they think is best and that agrees with the philosophy of the distribution they're maintaining the package for? I'm glad they don't have to justify their existences to upstream and every "significant portion[...] of users." > It's KeePassXC's job to secure the software and produce features that fulfill users' needs as they see fit. You don't control free software after you've licensed and distributed it that way. The entire point of the concept is to make calls like this about anti-features. KeePassXC can feel free to comment on it, like anyone else. They can demand that Debian make available the modified sources. They can revoke any license to the use of trademarks. That's it. If users only want to deal with KeePassXC, they can compile it themselves or use a portable version. If KeePassXC wants to deal with Debian users directly, they can host a package repository for their canonical version.

makeitdouble 2y ago

> KeePassXC's job Is KeepassXC even a company ? looking at their site and wikipedia, they're just a bunch of people dedicated enough to maintain the project. Looking at the donation page [0] they don't even list anything going to themselves in the use of the money. So they're effectively paying with their time to keep the thing alive. If anything the community seem to own a ton to these guys. [0] https://keepassxc.org/donate/ https://keepassxc.org/donate/

omoikane 2y ago
This reminds me of "The gift of it's your problem now" (2021): The best part of free software is it sometimes produces stuff you never would have been willing to pay to develop (Linux), and sometimes at quality levels too high to be rational for the market to provide (sqlite). The worst part of free software is you get what you get, and the developers don't have to listen to you. (And as a developer, the gift recipients aren't always so grateful either.) https://apenwarr.ca/log/20211229 https://apenwarr.ca/log/20211229 https://news.ycombinator.com/item?id=29736369 https://news.ycombinator.com/item?id=29736369

HumanProtractor 2y ago

Upstream's irrelevant to a maintainer. Downstream? Maintainers typically know best, that's why the user chose that distro. I bailed on Debian when they decided to go systemd. That's Democracy.

m-p-3 2y ago

The default build of KeepassXC is without any optional modules https://github.com/keepassxreboot/keepassxc/wiki/Building-KeePassXC#build-options https://github.com/keepassxreboot/keepassxc/wiki/Building-Ke... -DWITH_XC_ALL=[ON|OFF] Enable/Disable compiling all plugins above (default: OFF) To me, it seems like the maintainer is simply bringing the default package back to what it should have been, and he's offering another build with all features enabled under keepassxc-full If KeepassXC is unhappy with the defaults, they can adjust theirs to reflect what they feel should be available out of the box.

scovetta 2y ago

Obligatory article, "I am not a supplier.": <https://www.softwaremaxims.com/blog/not-a-supplier https://www.softwaremaxims.com/blog/not-a-supplier> Folks that disagree with a maintainer's actions are generally free to fork the project and maintain an alternative -- that's one of the primary features of open source software. And if end users prefer that new fork to the original maintainer's version, that'll probably be the one that survives. But maintainers have no obligation to make their end users happy.