12 ms·

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 th

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?
    - 0x_rs 2y ago
      >UPSTREAM THEMSELVES decided not to include in default/recommended build instructions This is false, or at the very least misleading. It doesn't take much to go on the repository and give a closer look instead of repeating "what other said". Kwpolska already wrote it in this thread, -DWITH_XC_ALL (the flag that's been turned OFF in the original Debian package rules) is explicitly called in the build instructions, and not only there but also one release tool [1] and snap config [2]. This is merely how the project manages its build configuration, with specific flags turned off and one master toggle enabled by default (or expected to be passed to cmake/bash release tool). Same thing for the ppa packaging. [3] 0. https://github.com/keepassxreboot/keepassxc/blob/develop/INSTALL.md#build-steps https://github.com/keepassxreboot/keepassxc/blob/develop/INS... 1. https://github.com/keepassxreboot/keepassxc/blob/da90319d2d04e5226d2363454c80a3c6cfe132e2/release-tool.ps1#L399 https://github.com/keepassxreboot/keepassxc/blob/da90319d2d0... 2. https://github.com/keepassxreboot/keepassxc/blob/da90319d2d04e5226d2363454c80a3c6cfe132e2/snap/snapcraft.yaml#L41 https://github.com/keepassxreboot/keepassxc/blob/da90319d2d0... 3. https://github.com/keepassxreboot/keepassxc-packaging/blob/9e493e38f6febe4d8da7228e9fddb8494976868a/ubuntu-ppa/focal/keepassxc/debian/rules#L22 https://github.com/keepassxreboot/keepassxc-packaging/blob/9...
- TehCorwiz 2y ago
  They're not "plugins". They're compiled in features. The Debian maintainer changed one compile flag and turned off these feature which are disabled by default in the UI anyway. And changing the compile flag didn't remove the options that enable the features from the UI. So, users are very confused why the features they're trying to use don't work. Further, what happens to existing users who had these features enabled and relied on them? EDIT: link to a KeeppassXC maintainer explaining that they're not plugins: https://github.com/keepassxreboot/keepassxc/issues/10725#issuecomment-2104508951 https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
  - NewJazz 2y ago
    Isn't this something that Debian can do during upgrades, though? Like sure there is breakage, if you don't read the news before upgrading major versions.
  - password4321 2y ago
    > changing the compile flag didn't remove the options that enable the features from the UI Hopefully this will get fixed
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.
rfoo 2y ago
Oh no, xscreensaver or GNU Parallel flame war once again.
temac 2y ago
> 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. What are you talking about? This is an upstream build option. Has upstream forked itself by providing this option?
- ErikBjare 2y ago
  That seems entirely fair to me.
zer00eyz 2y ago
IF apple said "hey we edited your app because we think its more secure"... People would have torches and pitchforks out. But a deb maintainer does it and there is debate? If there was a security issue then the insecure version should NOT be available. But again this is not the case. In an App Store world, the role of mainainter has to change. The job is to make the software work with the distro, not keep the name and make some pseudo fork because you want it to be another way.
- int_19h 2y ago
  Debian does this all the time. There are thousands of .deb packages that are built with patches. In this case, though, it's not even a patch - it's a build flag that is provided by upstream.
  - jdbernard 2y ago
    The fact that they are customizing the software is not really the issue. The issue is that they are making a change that will remove significant functionality and in some cases completely lock some users out of their password database, which is a huge deal. Imagine if you wake up tomorrow, run a software update and then can't log in to your bank? I imagine the reason this has blown up so much is that the maintainer never reached out to the upstream about this, and was rude and condescending when upstream reached out to them.
    - kasabali 2y ago
      > Imagine if you wake up tomorrow, run a software update and then can't log in to your bank Oh, the horror of being in unstable/testing channel and ignoring the change notice which has been shown automatically during apt-get upgrade.
      - redserk 2y ago
        The snark here is unnecessary and completely disconnected from how people use these systems in the real world. Deferring to “it’s in the notes!” means nothing if you have more than a handful of packages on your machine. You should also clarify the assertion that packaging affecting testing target won’t eventually hit stable, because that would be a major change that I haven’t heard about. An end user will get impacted by this eventually.
BLKNSLVR 2y ago
Isn't this just FOSS working as intended? There are lots of distributions other than Debian.
- deleted 2y ago
  [deleted]
kragen 2y ago
lots of debian packages are compiled without some compile flags that enable optional functionality; emacs, for example, comes in emacs-nox, emacs-gtk, and emacs-lucid, the last two of which use two different x-windows toolkits to give emacs a gui. (it's nice to not have to install a gui environment in order to have a text editor, see.) vim similarly has vim-tiny, vim-nox, vim-motif, and vim-gtk3 versions in this case it seems like the debian maintainer moved optional functionality that was opening security holes to the keepassxc-full package, and the keepassxc maintainers are lying about it by saying that he has 'decided to remove ALL features from it' in https://github.com/keepassxreboot/keepassxc/issues/10725 https://github.com/keepassxreboot/keepassxc/issues/10725 the debian maintainer explains: > 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. and yeah i really, really do not want my password manager to by default communicate with random web pages. that should be opt-in functionality and always should have been. given that it wasn't, there's no good option, but this is the least bad one one of the great benefits of free software is that it makes it hard for misguided or malicious maintainers to push antifeatures on users, because the users can always use somebody else's version of the software, for example, debian's or f-droid's. trusting debian to prevent shenanigans like the keepassxc team's is my biggest reason for using debian instead of something else
- netsharc 2y ago
  Your points are valid, but doing a switcheroo of someone's software is the stupid part... You say you trust Debian, but until this update, they've been allowing those horrible horrible shenanigans, on your system! Would you trust a security guard who for many years didn't notice a part of the building he should've checked for unlocked doors, until someone pointed it out to him?
  - kragen 2y ago
    it's a question of degree. i'd trust him more if he'd been checking it all along, but i'd trust him less if he decided that he shouldn't start checking it even after it was pointed out debian has made much worse security mistakes than that; i personally danced tango at debconf with the debian maintainer who introduced the openssl bug, which is arguably the worst computer security hole in human history basically the social practices of software development make computer security unattainable at any cost. we can try to improve that situation, but for the time being, debian is close to the best there is, even if it's not openbsd or sel4
mikepavone 2y ago
All they did was change the XC_ALL build parameter to OFF [0] which happens to be the default in upstream's CMakeLists.txt [1]. If upstream thinks this functionality is so important maybe they should fix their defaults. I think it's a bit unfortunate that users of this package may be confused why stuff stops working when they upgrade, but having the unsuffixed package match upstream defaults seems entirely reasonable otherwise. [0] https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f8de487b12266a1cb7975e2b7df2e3a4 https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f... [1] https://github.com/keepassxreboot/keepassxc/blob/develop/CMakeLists.txt#L51 https://github.com/keepassxreboot/keepassxc/blob/develop/CMa...
- dingensundso 2y ago
  At first I thought it should be the other way around. Keep the current keepassxc package and create a keepassxc-minimal. But seeing the build options it makes sense to have a keepassxc-full. Only thing is this will annoy some people when they upgrade. But only when this reaches stable and then there will be notice in the upgrade documentation and apt-listchangea.
- c-hendricks 2y ago
  > If upstream thinks this functionality is so important maybe they should fix their defaults. > none of these features are plugins. All of them are built-in functionality that belong to the main product. If anything, we will reduce the number of such compile-time flags in the future, so these things cannot be disabled anymore. https://github.com/keepassxreboot/keepassxc/issues/10725#issuecomment-2104750715 https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
  - mikepavone 2y ago
    That's certainly their prerogative, but I guess what I'm really trying to say is it's weird that they're so bent out of shape about a distro maintainer using a build option they added to their own code. Especially when said maintainer set it to the default they themselves set. If you were to download the source from github and follow the instructions in INSTALL.md which specify "Recommended CMake Build Parameters" you will end up with a binary with the exact same feature set as what the debian package now has. >> none of these features are plugins. I wasn't going to comment on this because it's a bit petty and is ultimately a boring semantic argument, but since you quoted it in a reply to me I will. Their CMakeLists.txt literally refers to these as plugins in the description of the XC_ALL param that was changed: "Build in all available plugins"
out-of-ideas 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 reminds me of busybox's implementations of: bash, sed, awk, ect and similar situations when folks go and ask 'how something-in bash works' then 'it doesnt work' all because of macos bash vs gnu bash, and forever on the battle goes with naming.
blablabla123 2y ago
Kind of interesting actually. In the 2000s/2010s it was quite normal that distributions provided modified packages. Maybe not necessarily function-wise but theming, config files to a degree that interoperability wasn't the best. Even more funny that this is done now by Debian which always had a reputation of providing vanilla packages... But I guess after the xz debacle this is getting a new kind of attention
- jdbernard 2y ago
  If this was the first time they were packaging keepassxc, this would be fine. If they instead chose to remove the keepassxc package and provide two new packages, keepassxc-minimal and keepassxc-full, it would be fine. It's the fact that the main package that people already have installed will no longer have functionality that many users depend on, breaking their configurations after an update.
  - kasabali 2y ago
    > people already have installed will no longer have functionality that many users depend on, breaking their configurations after an update. They'll have to type apt install keepassxc-full ENTER after reading about the packaging change which they've been shown during package update. Wow what a nuisance.
vsl 2y ago
Debian is the only distro with this weird attitude of disregard towards upstream. I maintain two upstream projects where Debian unilaterally decided to rename the package. In one case I found out much later, in the other case it was against my express objection and was completely nonsensical. Of course I’m the one who has to explain it to users. Edit: see the arrogance of the Debian guy (Julian) here: https://github.com/keepassxreboot/keepassxc/issues/10725#issuecomment-2104750715 https://github.com/keepassxreboot/keepassxc/issues/10725#iss... - that’s what I’m talking about.
- kasabali 2y ago
  What was your package named?

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?
  - 0x_rs 2y ago
    >UPSTREAM THEMSELVES decided not to include in default/recommended build instructions This is false, or at the very least misleading. It doesn't take much to go on the repository and give a closer look instead of repeating "what other said". Kwpolska already wrote it in this thread, -DWITH_XC_ALL (the flag that's been turned OFF in the original Debian package rules) is explicitly called in the build instructions, and not only there but also one release tool [1] and snap config [2]. This is merely how the project manages its build configuration, with specific flags turned off and one master toggle enabled by default (or expected to be passed to cmake/bash release tool). Same thing for the ppa packaging. [3] 0. https://github.com/keepassxreboot/keepassxc/blob/develop/INSTALL.md#build-steps https://github.com/keepassxreboot/keepassxc/blob/develop/INS... 1. https://github.com/keepassxreboot/keepassxc/blob/da90319d2d04e5226d2363454c80a3c6cfe132e2/release-tool.ps1#L399 https://github.com/keepassxreboot/keepassxc/blob/da90319d2d0... 2. https://github.com/keepassxreboot/keepassxc/blob/da90319d2d04e5226d2363454c80a3c6cfe132e2/snap/snapcraft.yaml#L41 https://github.com/keepassxreboot/keepassxc/blob/da90319d2d0... 3. https://github.com/keepassxreboot/keepassxc-packaging/blob/9e493e38f6febe4d8da7228e9fddb8494976868a/ubuntu-ppa/focal/keepassxc/debian/rules#L22 https://github.com/keepassxreboot/keepassxc-packaging/blob/9...
TehCorwiz 2y ago
They're not "plugins". They're compiled in features. The Debian maintainer changed one compile flag and turned off these feature which are disabled by default in the UI anyway. And changing the compile flag didn't remove the options that enable the features from the UI. So, users are very confused why the features they're trying to use don't work. Further, what happens to existing users who had these features enabled and relied on them? EDIT: link to a KeeppassXC maintainer explaining that they're not plugins: https://github.com/keepassxreboot/keepassxc/issues/10725#issuecomment-2104508951 https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
- NewJazz 2y ago
  Isn't this something that Debian can do during upgrades, though? Like sure there is breakage, if you don't read the news before upgrading major versions.
- password4321 2y ago
  > changing the compile flag didn't remove the options that enable the features from the UI Hopefully this will get fixed

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.

rfoo 2y ago

Oh no, xscreensaver or GNU Parallel flame war once again.

temac 2y ago

> 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. What are you talking about? This is an upstream build option. Has upstream forked itself by providing this option?

ErikBjare 2y ago
That seems entirely fair to me.

zer00eyz 2y ago

IF apple said "hey we edited your app because we think its more secure"... People would have torches and pitchforks out. But a deb maintainer does it and there is debate? If there was a security issue then the insecure version should NOT be available. But again this is not the case. In an App Store world, the role of mainainter has to change. The job is to make the software work with the distro, not keep the name and make some pseudo fork because you want it to be another way.

int_19h 2y ago
Debian does this all the time. There are thousands of .deb packages that are built with patches. In this case, though, it's not even a patch - it's a build flag that is provided by upstream.
- jdbernard 2y ago
  The fact that they are customizing the software is not really the issue. The issue is that they are making a change that will remove significant functionality and in some cases completely lock some users out of their password database, which is a huge deal. Imagine if you wake up tomorrow, run a software update and then can't log in to your bank? I imagine the reason this has blown up so much is that the maintainer never reached out to the upstream about this, and was rude and condescending when upstream reached out to them.
  - kasabali 2y ago
    > Imagine if you wake up tomorrow, run a software update and then can't log in to your bank Oh, the horror of being in unstable/testing channel and ignoring the change notice which has been shown automatically during apt-get upgrade.
    - redserk 2y ago
      The snark here is unnecessary and completely disconnected from how people use these systems in the real world. Deferring to “it’s in the notes!” means nothing if you have more than a handful of packages on your machine. You should also clarify the assertion that packaging affecting testing target won’t eventually hit stable, because that would be a major change that I haven’t heard about. An end user will get impacted by this eventually.

BLKNSLVR 2y ago

Isn't this just FOSS working as intended? There are lots of distributions other than Debian.

deleted 2y ago
[deleted]

kragen 2y ago

lots of debian packages are compiled without some compile flags that enable optional functionality; emacs, for example, comes in emacs-nox, emacs-gtk, and emacs-lucid, the last two of which use two different x-windows toolkits to give emacs a gui. (it's nice to not have to install a gui environment in order to have a text editor, see.) vim similarly has vim-tiny, vim-nox, vim-motif, and vim-gtk3 versions in this case it seems like the debian maintainer moved optional functionality that was opening security holes to the keepassxc-full package, and the keepassxc maintainers are lying about it by saying that he has 'decided to remove ALL features from it' in https://github.com/keepassxreboot/keepassxc/issues/10725 https://github.com/keepassxreboot/keepassxc/issues/10725 the debian maintainer explains: > 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. and yeah i really, really do not want my password manager to by default communicate with random web pages. that should be opt-in functionality and always should have been. given that it wasn't, there's no good option, but this is the least bad one one of the great benefits of free software is that it makes it hard for misguided or malicious maintainers to push antifeatures on users, because the users can always use somebody else's version of the software, for example, debian's or f-droid's. trusting debian to prevent shenanigans like the keepassxc team's is my biggest reason for using debian instead of something else

netsharc 2y ago
Your points are valid, but doing a switcheroo of someone's software is the stupid part... You say you trust Debian, but until this update, they've been allowing those horrible horrible shenanigans, on your system! Would you trust a security guard who for many years didn't notice a part of the building he should've checked for unlocked doors, until someone pointed it out to him?
- kragen 2y ago
  it's a question of degree. i'd trust him more if he'd been checking it all along, but i'd trust him less if he decided that he shouldn't start checking it even after it was pointed out debian has made much worse security mistakes than that; i personally danced tango at debconf with the debian maintainer who introduced the openssl bug, which is arguably the worst computer security hole in human history basically the social practices of software development make computer security unattainable at any cost. we can try to improve that situation, but for the time being, debian is close to the best there is, even if it's not openbsd or sel4

mikepavone 2y ago

All they did was change the XC_ALL build parameter to OFF [0] which happens to be the default in upstream's CMakeLists.txt [1]. If upstream thinks this functionality is so important maybe they should fix their defaults. I think it's a bit unfortunate that users of this package may be confused why stuff stops working when they upgrade, but having the unsuffixed package match upstream defaults seems entirely reasonable otherwise. [0] https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f8de487b12266a1cb7975e2b7df2e3a4 https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f... [1] https://github.com/keepassxreboot/keepassxc/blob/develop/CMakeLists.txt#L51 https://github.com/keepassxreboot/keepassxc/blob/develop/CMa...

dingensundso 2y ago
At first I thought it should be the other way around. Keep the current keepassxc package and create a keepassxc-minimal. But seeing the build options it makes sense to have a keepassxc-full. Only thing is this will annoy some people when they upgrade. But only when this reaches stable and then there will be notice in the upgrade documentation and apt-listchangea.
c-hendricks 2y ago
> If upstream thinks this functionality is so important maybe they should fix their defaults. > none of these features are plugins. All of them are built-in functionality that belong to the main product. If anything, we will reduce the number of such compile-time flags in the future, so these things cannot be disabled anymore. https://github.com/keepassxreboot/keepassxc/issues/10725#issuecomment-2104750715 https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
- mikepavone 2y ago
  That's certainly their prerogative, but I guess what I'm really trying to say is it's weird that they're so bent out of shape about a distro maintainer using a build option they added to their own code. Especially when said maintainer set it to the default they themselves set. If you were to download the source from github and follow the instructions in INSTALL.md which specify "Recommended CMake Build Parameters" you will end up with a binary with the exact same feature set as what the debian package now has. >> none of these features are plugins. I wasn't going to comment on this because it's a bit petty and is ultimately a boring semantic argument, but since you quoted it in a reply to me I will. Their CMakeLists.txt literally refers to these as plugins in the description of the XC_ALL param that was changed: "Build in all available plugins"

out-of-ideas 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 reminds me of busybox's implementations of: bash, sed, awk, ect and similar situations when folks go and ask 'how something-in bash works' then 'it doesnt work' all because of macos bash vs gnu bash, and forever on the battle goes with naming.

blablabla123 2y ago

Kind of interesting actually. In the 2000s/2010s it was quite normal that distributions provided modified packages. Maybe not necessarily function-wise but theming, config files to a degree that interoperability wasn't the best. Even more funny that this is done now by Debian which always had a reputation of providing vanilla packages... But I guess after the xz debacle this is getting a new kind of attention

jdbernard 2y ago
If this was the first time they were packaging keepassxc, this would be fine. If they instead chose to remove the keepassxc package and provide two new packages, keepassxc-minimal and keepassxc-full, it would be fine. It's the fact that the main package that people already have installed will no longer have functionality that many users depend on, breaking their configurations after an update.
- kasabali 2y ago
  > people already have installed will no longer have functionality that many users depend on, breaking their configurations after an update. They'll have to type apt install keepassxc-full ENTER after reading about the packaging change which they've been shown during package update. Wow what a nuisance.

vsl 2y ago

Debian is the only distro with this weird attitude of disregard towards upstream. I maintain two upstream projects where Debian unilaterally decided to rename the package. In one case I found out much later, in the other case it was against my express objection and was completely nonsensical. Of course I’m the one who has to explain it to users. Edit: see the arrogance of the Debian guy (Julian) here: https://github.com/keepassxreboot/keepassxc/issues/10725#issuecomment-2104750715 https://github.com/keepassxreboot/keepassxc/issues/10725#iss... - that’s what I’m talking about.

kasabali 2y ago
What was your package named?