8 ms·

The role of a maintainer is more than copying and pasting upstream. They are allowed to exercise their judgement in what they believe is appropriate for end use

by dannyw 2y ago

The role of a maintainer is more than copying and pasting upstream. They are allowed to exercise their judgement in what they believe is appropriate for end users of a distribution. In this case, there does seem to be reasonable security justifications for it, and an alternative is provided.

winternewt 2y ago
You can do all that and still honor the points of the parent comment though. I agree that it's poor etiquette to make intrusive changes and hold the original author accountable for them.
thaumaturgy 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? 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.
tdb7893 2y ago
Having things named the same across platforms but with significantly different features is a usability nightmare. They even created a package that does have all the same functionality but named it something different, if you're gonna change the functionality from other platforms then that's the one that should have a different name.
dataflow 2y ago
> The role of a maintainer is more than copying and pasting upstream They can do that... under a name that doesn't mislead people. Is that so hard?
Gud 2y ago
They should not alter basic functionality. Their sole job is to make the software work on their platform. I would be pissed if a FreeBSD package was some non-standard configuration.
- quectophoton 2y ago
  Disclaimer: I don't use Debian, so I don't have a horse in this race. > I would be pissed if a FreeBSD package was some non-standard configuration. I'm of two minds here. On one hand, I agree that I would like packages to be packaged as similar to upstream as possible (even if this has also caused annoying changes during upgrades). On the other hand, I appreciate when package maintainers remove things like enabled-by-default telemetry (which is a whole another topic of its own). Of course for both cases one should at least skim over the post-installation messages, or whatever they're called. To look for deprecation notices, additional instructions, messages like "if you need X feature please install such package", etc. So if I don't read these messages, which appear right at the end of the install/upgrade process (can't miss them), that's my fault. If I don't do a zpool checkpoint before upgrading, that's my fault. If I don't verify important or major stuff (like my password manager, web browser, rebooting to ensure graphics drivers still work, etc) after the upgrade and before deleting the zpool checkpoint, that's my fault. If I didn't at least skim the list of package that were going to be upgraded, that's my fault. If I didn't backup my zfs mirror to a separate, plugged out drive before doing a major FreeBSD version upgrade, and the upgrade goes wrong, and I don't have any way to restore the pool to how it was before the upgrade, oh you better believe that's my fault. (EDIT: Sorry for the long paddlin' reference but the TL;DR is that, if something breaks, half of the responsibility lies on the user.) Changing topic back to TFA and Debian. Whether or not the Debian maintainer followed proper procedure for such a change, is a good question because there's not only the maintainer, but also Debian itself. So I'm kinda waiting to see if there's any response from someone higher up the Debian chain of command; if they (whoever writes the "Debian maintainer rules") consider this acceptable for a maintainer to do, or if they will issue a warning saying this was something not acceptable and "might lead to losing maintainer status if it repeats in the future".
JeremyNT 2y ago
Maybe Debian maintainers consider it their role to do this, but that's absolutely not true in other distributions (e.g., one reason I use Arch is to avoid such tinkering). Down this road lies problems with incompatibilities and new bugs that are distro-specific. As a user it defies my expectations to have software modified to remove functionality and retain the same name. This is a bit too opinionated for my tastes.
- rcxdude 2y ago
  This. As a user and a developer I've had more than a few run-ins with a distro deciding to be a bit different, usually with no very weak justification (pedantic interpretations of some standard, attempts to make something 'neat', or just random changes that someone thought would be cool). Debian is especially bad at this, Arch tends to be better but they've also done some stupid things (python-as-python3 being a thorn in so many developer's side for years).
cycomanic 2y ago
The justification is absolute rubbish. I The argument is that it reduces attack surface, but compared to what, the alternative to including the yubikey code is not using a yubikey, which reduces security. The alternative to using the browser integration (or the ssh agent) is to use the clipboard, which is likely more code and definitely less vetted code. By the same argument we should remove encryption as well, because it increases the amount of code and thus the attack surface.
- undersuit 2y ago
  >the alternative to including the yubikey code is not using a yubikey, which reduces security. The physics of someone cracking my passphrase and the physics of someone cracking my Yubikey are both in the boil the oceans amount of energy. I'm fine not letting a usb device masquerading as a keyboard have access to my password database. Remember: "When you lose your YubiKey or someone else gets access to it, your database is not secure anymore."
  - lawn 2y ago
    > When you lose your YubiKey or someone else gets access to it, your database is not secure anymore. You don't store your password on the YubiKey, you use it as a second factor in addition to your password. Do you know what a YubiKey is when you argue against it?
    - undersuit 2y ago
      You can add different kinds of authentication to your password safe. I use a password and a key file. You can use just the Yubikey just like you can also have no encryption applied to the password safe.
  - valicord 2y ago
    What is the physics of someone sniffing your passphrase with a keylogger?
    - 2y ago
vilunov 2y ago
I don't understand the need of such a role at all. It's fine if it's the OS-level software, but for end-user applications such as KeePass I'd prefer that there would be no intermediaries between the developers of the app and the users. You don't need to repackage every piece of software that your users might want to use, let developers target your OS on their own by providing a stable set of APIs and ABIs, otherwise it's not really an OS.

by dannyw 2y ago

winternewt 2y ago

You can do all that and still honor the points of the parent comment though. I agree that it's poor etiquette to make intrusive changes and hold the original author accountable for them.

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

tdb7893 2y ago

Having things named the same across platforms but with significantly different features is a usability nightmare. They even created a package that does have all the same functionality but named it something different, if you're gonna change the functionality from other platforms then that's the one that should have a different name.

dataflow 2y ago

> The role of a maintainer is more than copying and pasting upstream They can do that... under a name that doesn't mislead people. Is that so hard?

Gud 2y ago

They should not alter basic functionality. Their sole job is to make the software work on their platform. I would be pissed if a FreeBSD package was some non-standard configuration.

quectophoton 2y ago
Disclaimer: I don't use Debian, so I don't have a horse in this race. > I would be pissed if a FreeBSD package was some non-standard configuration. I'm of two minds here. On one hand, I agree that I would like packages to be packaged as similar to upstream as possible (even if this has also caused annoying changes during upgrades). On the other hand, I appreciate when package maintainers remove things like enabled-by-default telemetry (which is a whole another topic of its own). Of course for both cases one should at least skim over the post-installation messages, or whatever they're called. To look for deprecation notices, additional instructions, messages like "if you need X feature please install such package", etc. So if I don't read these messages, which appear right at the end of the install/upgrade process (can't miss them), that's my fault. If I don't do a zpool checkpoint before upgrading, that's my fault. If I don't verify important or major stuff (like my password manager, web browser, rebooting to ensure graphics drivers still work, etc) after the upgrade and before deleting the zpool checkpoint, that's my fault. If I didn't at least skim the list of package that were going to be upgraded, that's my fault. If I didn't backup my zfs mirror to a separate, plugged out drive before doing a major FreeBSD version upgrade, and the upgrade goes wrong, and I don't have any way to restore the pool to how it was before the upgrade, oh you better believe that's my fault. (EDIT: Sorry for the long paddlin' reference but the TL;DR is that, if something breaks, half of the responsibility lies on the user.) Changing topic back to TFA and Debian. Whether or not the Debian maintainer followed proper procedure for such a change, is a good question because there's not only the maintainer, but also Debian itself. So I'm kinda waiting to see if there's any response from someone higher up the Debian chain of command; if they (whoever writes the "Debian maintainer rules") consider this acceptable for a maintainer to do, or if they will issue a warning saying this was something not acceptable and "might lead to losing maintainer status if it repeats in the future".

JeremyNT 2y ago

Maybe Debian maintainers consider it their role to do this, but that's absolutely not true in other distributions (e.g., one reason I use Arch is to avoid such tinkering). Down this road lies problems with incompatibilities and new bugs that are distro-specific. As a user it defies my expectations to have software modified to remove functionality and retain the same name. This is a bit too opinionated for my tastes.

rcxdude 2y ago
This. As a user and a developer I've had more than a few run-ins with a distro deciding to be a bit different, usually with no very weak justification (pedantic interpretations of some standard, attempts to make something 'neat', or just random changes that someone thought would be cool). Debian is especially bad at this, Arch tends to be better but they've also done some stupid things (python-as-python3 being a thorn in so many developer's side for years).

cycomanic 2y ago

The justification is absolute rubbish. I The argument is that it reduces attack surface, but compared to what, the alternative to including the yubikey code is not using a yubikey, which reduces security. The alternative to using the browser integration (or the ssh agent) is to use the clipboard, which is likely more code and definitely less vetted code. By the same argument we should remove encryption as well, because it increases the amount of code and thus the attack surface.

undersuit 2y ago
>the alternative to including the yubikey code is not using a yubikey, which reduces security. The physics of someone cracking my passphrase and the physics of someone cracking my Yubikey are both in the boil the oceans amount of energy. I'm fine not letting a usb device masquerading as a keyboard have access to my password database. Remember: "When you lose your YubiKey or someone else gets access to it, your database is not secure anymore."
- lawn 2y ago
  > When you lose your YubiKey or someone else gets access to it, your database is not secure anymore. You don't store your password on the YubiKey, you use it as a second factor in addition to your password. Do you know what a YubiKey is when you argue against it?
  - undersuit 2y ago
    You can add different kinds of authentication to your password safe. I use a password and a key file. You can use just the Yubikey just like you can also have no encryption applied to the password safe.
- valicord 2y ago
  What is the physics of someone sniffing your passphrase with a keylogger?
  - 2y ago

vilunov 2y ago

I don't understand the need of such a role at all. It's fine if it's the OS-level software, but for end-user applications such as KeePass I'd prefer that there would be no intermediaries between the developers of the app and the users. You don't need to repackage every piece of software that your users might want to use, let developers target your OS on their own by providing a stable set of APIs and ABIs, otherwise it's not really an OS.