KeePassXC Debian maintainer has removed all network features(fosstodon.org)
fosstodon.org
KeePassXC Debian maintainer has removed all network features
https://fosstodon.org/@keepassxc/112417353193348720
366 comments
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/7d6d16e3f... [1] https://github.com/keepassxreboot/keepassxc/blob/develop/CMa...
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/7d6d16e3f... [1] https://github.com/keepassxreboot/keepassxc/blob/develop/CMa...
> 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#iss...
> 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#iss...
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"
>> 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"
INSTALL.md [0] recommends passing -DWITH_XC_ALL in the Build Steps section.
This build option exists. If you're building from source and don't need any of the extra features, you can use it to get a leaner binary. But the Debian maintainer made this decision for everybody, removing important security features (such as browser integration and YubiKey support) from the main `keepassxc` package, which broke people's existing installations, and which means that people blindly running `sudo apt install keepassxc` will get an inferior, less secure product.
[0] https://github.com/keepassxreboot/keepassxc/blob/develop/INS...
This build option exists. If you're building from source and don't need any of the extra features, you can use it to get a leaner binary. But the Debian maintainer made this decision for everybody, removing important security features (such as browser integration and YubiKey support) from the main `keepassxc` package, which broke people's existing installations, and which means that people blindly running `sudo apt install keepassxc` will get an inferior, less secure product.
[0] https://github.com/keepassxreboot/keepassxc/blob/develop/INS...
> INSTALL.md [0] recommends passing -DWITH_XC_ALL in the Build Steps section.
You're right, I missed it there. Silly me for assuming that all of the recommended CMake flags would be specified in the section titled "Recommended CMake Build Parameters"
You're right, I missed it there. Silly me for assuming that all of the recommended CMake flags would be specified in the section titled "Recommended CMake Build Parameters"
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.
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.
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.
In this case, there does seem to be reasonable security justifications for it, and an alternative is provided.
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.
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.
> 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/
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/
This reminds me of "The gift of it's your problem now" (2021):
https://news.ycombinator.com/item?id=29736369
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://news.ycombinator.com/item?id=29736369
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
I anticipated this reply, either here or elsewhere, and was really hoping it wouldn't arrive.
I do a lot of volunteer work too. Guess what? My decisions in those roles are not unimpeachable. Being a volunteer also does not mean you are owed anything, even gratitude. It's a thing you choose to do, and if you don't like doing it anymore, then you should stop doing it.
Package maintainers aren't self-sacrificial saints or all that unique as volunteers go.
This is a bad decision. It deserves criticism and discussion. The volunteer status of package maintainership is irrelevant.
I do a lot of volunteer work too. Guess what? My decisions in those roles are not unimpeachable. Being a volunteer also does not mean you are owed anything, even gratitude. It's a thing you choose to do, and if you don't like doing it anymore, then you should stop doing it.
Package maintainers aren't self-sacrificial saints or all that unique as volunteers go.
This is a bad decision. It deserves criticism and discussion. The volunteer status of package maintainership is irrelevant.
I share your frustration because comments like that show up in every thread about open source.
By putting something out into the world you're creating connections with others. If people like what you've built and start to rely on it then that puts power into your hands, and any time you have power over others it should be wielded responsibly.
Volunteering doesn't give people a pass to screw over others.
By putting something out into the world you're creating connections with others. If people like what you've built and start to rely on it then that puts power into your hands, and any time you have power over others it should be wielded responsibly.
Volunteering doesn't give people a pass to screw over others.
And who decides "responsible"? The mantainer made the decision of defaulting to no-network for safety reasons, that users can reverse with a flag. This sounds responsible enough for me.
I bet that if a bug is found in the connection API and passwords leak, we would impale the head of the mantainer in a pike for not defaulting to safe mode, or to have connection at all.
I bet that if a bug is found in the connection API and passwords leak, we would impale the head of the mantainer in a pike for not defaulting to safe mode, or to have connection at all.
And the software authors made it clear that those features, even if compiled in, are disabled by default and the code never executes.
Connecting the internet and a password database together is one of those fundamentally bad ideas. This might well be an excellent technical decision. Although I agree with the thread root that this is a level of intervention that might justify some rebranding.
> Package maintainers aren't self-sacrificial saints or all that unique as volunteers go.
If you want keepassx, you can go install it. If you want the Debian archive's version, install that. All the options are open to critique, but the average Debian maintainer is doing so much more good than the occasional bad decision that they get a lot of benefit-of-doubt on this sort of choice. And some reasonable expectations of respect.
> Package maintainers aren't self-sacrificial saints or all that unique as volunteers go.
If you want keepassx, you can go install it. If you want the Debian archive's version, install that. All the options are open to critique, but the average Debian maintainer is doing so much more good than the occasional bad decision that they get a lot of benefit-of-doubt on this sort of choice. And some reasonable expectations of respect.
Is it a _fundamentally_ bad idea? The connected syncing feature of Bitwarden is one of my favorite things. I can save a password on one device, and its automagically available on others all while staying encrypted (and audited).
Agreed but it is worth keeping in mind that Bitwarden's implementation of sync is probably a lot more sophisticated than KeepassXC; and is probably the main reason why one would use Bitwarden. I am a former user of Keepass and I never knew it had network functionality so I think it makes sense to provide two packages -- one containing the main keepass functions which which 99% of users will use and the othrer for the 1% using the exotic functions. This is in line with how Debian handles many other packages such as vim, exim, etc so it is not at all surprising for the typical Debian user.
KeePassXC has no sync implementation.
The functions related to Internet are:
- getting the favicon for a specific entry (needs to be ran manually with an option to download via a DuckDuckGo proxy)
- checking entries against HIBP (needs to be done manually in a submenu with a giant notice)
Also this is about KeePassXC not KeePass which is a completely different project. There is also KeePassX, KeePassDX, KeeWeb, KeePass-electron and so on and so forth.
The functions related to Internet are:
- getting the favicon for a specific entry (needs to be ran manually with an option to download via a DuckDuckGo proxy)
- checking entries against HIBP (needs to be done manually in a submenu with a giant notice)
Also this is about KeePassXC not KeePass which is a completely different project. There is also KeePassX, KeePassDX, KeeWeb, KeePass-electron and so on and so forth.
> And some reasonable expectations of respect.
I think that expectation ends once you start calling the other party's software "crappy".
I think that expectation ends once you start calling the other party's software "crappy".
> Connecting the internet and a password database together is one of those fundamentally bad ideas.
Disagree. I use KeePassXC because I would prefer to have my passwords on my computer, instead of somebody else's computer (and I am willing to accept responsibility for managing my own password file).
That is a delineation that is parallel to, but not the same as, "don't connect to the internet". Browser integration is a required feature for a modern password manager; without it, you don't have a password manager, you have an encrypted notepad. HIBP integration is, likewise, net-good for users.
Also, as the KeePassXC devs have repeatedly pointed out in multiple places, these features are compiled in, but not enabled by default. Users who do not wish to use them can simply ignore them. Julian's argument at best seems to be some kind of concern about software supply chain; he is compiling the package without these features so that they are no longer available to the users who do want them.
The people making the arguments in favor of this change "for security reasons" aren't even making strong arguments for it.
> If you want keepassx, you can go install it...
Okay. And if you want a super-paranoid version of KeePassXC without these features compiled in, you can... go compile it that way.
Like everyone else, I already have thousands of little time sinks to contend with simultaneous to other increasing pressures in life. I am investing some time now to try to prevent another bad decision from adding to those faffs.
> some reasonable expectations of respect.
First, from my reading here and on the Mastodon thread and on the GitHub thread, most people have expressed dissatisfaction with this decision without crossing the line into disrespect towards the maintainer. The KeePassXC devs have maybe gotten a little heated, but they deserve all the same allowances you'd give to a package maintainer. They are getting bug reports due to downstream's decision, which they strongly disagree with. That sucks. There is a little bit of the usual internet noise, but otherwise, this is about the best discourse that could be expected for something like this.
Second, Julian himself kinda invited a strong negative response when he replied early on with, "This will be painful for a year as users annoyingly do not read the NEWS files they should be reading but there's little that can be done about that. ... 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..."
---
Getting back to some substantive discussion, it seems unlikely Julian is going to change his mind on this. This seems like a clear failure of package stewardship to me; KeePassXC's best move IMO is to set up their own repository and provide instructions for adding their repo and key to apt and then pin their keepassxc package. It's a bit of a nuisance for them, but probably less headache than ongoing bug reports and noise from the internet. There's already a lot of other software that gets installed this way, so I think it's fair to expect the average Debian user to be able to handle this process -- it's copy-and-pasting about four lines into your terminal. Then, Julian will no longer need to bear the burden of maintaining the package.
Disagree. I use KeePassXC because I would prefer to have my passwords on my computer, instead of somebody else's computer (and I am willing to accept responsibility for managing my own password file).
That is a delineation that is parallel to, but not the same as, "don't connect to the internet". Browser integration is a required feature for a modern password manager; without it, you don't have a password manager, you have an encrypted notepad. HIBP integration is, likewise, net-good for users.
Also, as the KeePassXC devs have repeatedly pointed out in multiple places, these features are compiled in, but not enabled by default. Users who do not wish to use them can simply ignore them. Julian's argument at best seems to be some kind of concern about software supply chain; he is compiling the package without these features so that they are no longer available to the users who do want them.
The people making the arguments in favor of this change "for security reasons" aren't even making strong arguments for it.
> If you want keepassx, you can go install it...
Okay. And if you want a super-paranoid version of KeePassXC without these features compiled in, you can... go compile it that way.
Like everyone else, I already have thousands of little time sinks to contend with simultaneous to other increasing pressures in life. I am investing some time now to try to prevent another bad decision from adding to those faffs.
> some reasonable expectations of respect.
First, from my reading here and on the Mastodon thread and on the GitHub thread, most people have expressed dissatisfaction with this decision without crossing the line into disrespect towards the maintainer. The KeePassXC devs have maybe gotten a little heated, but they deserve all the same allowances you'd give to a package maintainer. They are getting bug reports due to downstream's decision, which they strongly disagree with. That sucks. There is a little bit of the usual internet noise, but otherwise, this is about the best discourse that could be expected for something like this.
Second, Julian himself kinda invited a strong negative response when he replied early on with, "This will be painful for a year as users annoyingly do not read the NEWS files they should be reading but there's little that can be done about that. ... 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..."
---
Getting back to some substantive discussion, it seems unlikely Julian is going to change his mind on this. This seems like a clear failure of package stewardship to me; KeePassXC's best move IMO is to set up their own repository and provide instructions for adding their repo and key to apt and then pin their keepassxc package. It's a bit of a nuisance for them, but probably less headache than ongoing bug reports and noise from the internet. There's already a lot of other software that gets installed this way, so I think it's fair to expect the average Debian user to be able to handle this process -- it's copy-and-pasting about four lines into your terminal. Then, Julian will no longer need to bear the burden of maintaining the package.
> Browser integration is a required feature for a modern password manager; without it, you don't have a password manager, you have an encrypted notepad.
Not really? I've been using KeePassXC without a browser extension for a while, probably not years but certainly many months. That doesn't make it any less of a password manager - it lets me generate random strings to use for each account, keeps them safe and encrypted, and also lets me enable TOTP for an unlimited number of accounts. That's pretty much a password manager to me (TOTP is extra but much appreciated).
Not really? I've been using KeePassXC without a browser extension for a while, probably not years but certainly many months. That doesn't make it any less of a password manager - it lets me generate random strings to use for each account, keeps them safe and encrypted, and also lets me enable TOTP for an unlimited number of accounts. That's pretty much a password manager to me (TOTP is extra but much appreciated).
It makes you vulnerable to phishing (or rather, it provides zero protection against phishing), which is one of the biggest threats to the average user by a wide margin.
It's absolutely reasonable to say "Browser integration is a required feature for a modern password manager".
It's absolutely reasonable to say "Browser integration is a required feature for a modern password manager".
>And some reasonable expectations of respect.
Volunteers by definition do not (or at least should not) expect anything in return for their time. If you want respect as a so-called volunteer, you're not a volunteer.
I've seen both good and bad package maintainers, too.
Volunteers by definition do not (or at least should not) expect anything in return for their time. If you want respect as a so-called volunteer, you're not a volunteer.
I've seen both good and bad package maintainers, too.
> Volunteers by definition do not (or at least should not) expect anything in return for their time
That isn't really true. For starters, paid volunteers are actually a thing that happens from time to time. Secondly; there would be no volunteers if they didn't get something for their time. It is just generally that something isn't money. Volunteers aren't expected to be selfless.
That isn't really true. For starters, paid volunteers are actually a thing that happens from time to time. Secondly; there would be no volunteers if they didn't get something for their time. It is just generally that something isn't money. Volunteers aren't expected to be selfless.
If you’re getting paid you’re by definition not a volunteer. You may be getting some perks like volunteering at a convention giving you an entry pass for that convention, but as soon as you’re getting some other gains, be it monetary or not, you’re no longer a volunteer.
each year, my employer allows me to take a (paid) day off to do volunteering projects, e.g. going to soup kitchens. I get paid for that day regularly by my employer. The soup kitchen doesn't have to pay a dime.
Am I a volunteer?
Am I a volunteer?
to the soup kitchen, yes, you are, if they aren't paying you.
> If you’re getting paid you’re by definition not a volunteer.
You are technically incorrect. The US army, for example, is manned more or less entirely with paid volunteers.
And while many volunteers may not get formal compensation, they have to expect to get something out of the experience. Otherwise they would not do it. The subset of volunteers who are in it purely for a biblically pure sense of charity is tiny. And there is no expectation that Debian developers are motivated by some cultish wish to do good for the sake of free software. They're allowed to be motivated by whatever motivates them to do good with free software. Even if it is money.
You are technically incorrect. The US army, for example, is manned more or less entirely with paid volunteers.
And while many volunteers may not get formal compensation, they have to expect to get something out of the experience. Otherwise they would not do it. The subset of volunteers who are in it purely for a biblically pure sense of charity is tiny. And there is no expectation that Debian developers are motivated by some cultish wish to do good for the sake of free software. They're allowed to be motivated by whatever motivates them to do good with free software. Even if it is money.
>they have to expect to get something out of the experience.
Volunteers are in it for the satisfaction of volunteering.
If you want anything beyond that as compensation for volunteering, you are by definition not volunteering.
Incidentally, those who receive monetary compensation for their time and work are known as professionals.
Volunteers are in it for the satisfaction of volunteering.
If you want anything beyond that as compensation for volunteering, you are by definition not volunteering.
Incidentally, those who receive monetary compensation for their time and work are known as professionals.
I agree volunteering doesn't mean decisions can't be criticized, but the notion of duty towards the user oversteps that.
The same way maintainers make their decisions, the community is free to deal with it in any way shape or form. As long as money or malice or recklessness isn't involved, people should be free to do what they think is right, and the current maintainers aren't putting any roadblocks to prevent others from using the work in the way they want.
The same way maintainers make their decisions, the community is free to deal with it in any way shape or form. As long as money or malice or recklessness isn't involved, people should be free to do what they think is right, and the current maintainers aren't putting any roadblocks to prevent others from using the work in the way they want.
They don't owe us anything, but that's completely unrelated to the current discussion. They can be completely free to do whatever they want, and users can also disagree with that and voice said disagreement. It's a two way street. Especially in a situation where there's only "one" maintainer per package per distro, meaning that users of the distro (who can be other maintainers too) can disagree with it and openly so. There's a reason why Debian doesn't allow a maintainer to say, gut systemd or switch to another init system unilaterally just because they are volunteering to maintain the package
This line is always ludicrous because it doesn’t play in literally any other volunteering scenario. In a previous life I coordinated volunteers. You better believe that I still held them to a standard and told them their time was better spent elsewhere if they didn’t want to play by the rules. “But they’re volunteering!” Is a uniquely open source contributor mindset that only seeks to perpetuate some nerd’s weird fiefdom. The reality is that for some people, they’re just…fine not getting paid with money, because what they’re really after is something to control.
At the end of the day the volunteer is a volunteer for the Debian project (not KeepassXC or others) and doing what is deemed right for the Debian project. I agree volunteers should be held to a high standard, although I suspect in this case the volunteer is maintaining Debian's high standards. As a Debian user the volunteer's decision seems in line with Debian's ethos.
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.
> Their job is building a working .deb with working software
If that were was all there is to packaging - upstream developers could do the same job & have their CI/CD pipeline shoot out a .deb file.
However, it's not unheard of for package managers to maintain an evolving patchset that changes the default behavior and better integrates the upstream project to the rest of the distribution and its philosophy.
If that were was all there is to packaging - upstream developers could do the same job & have their CI/CD pipeline shoot out a .deb file.
However, it's not unheard of for package managers to maintain an evolving patchset that changes the default behavior and better integrates the upstream project to the rest of the distribution and its philosophy.
Upstream developers don’t have the time and bandwidth to set up packaging for all distros and versions.
Improving defaults may be fine according to some. Removing major features advertised by the software due to political reasons is not fine.
My software is a victim of Debian maintainers as well: they chose to remove the default theme from our static site generator, because it was built on top of Bootstrap 3, but Debian only shipped Bootstrap 2 at the time in a global package (they also changed the bootstrap 2 theme to use symlinks to the global version). How is this “better integration with the philosophy”?
Improving defaults may be fine according to some. Removing major features advertised by the software due to political reasons is not fine.
My software is a victim of Debian maintainers as well: they chose to remove the default theme from our static site generator, because it was built on top of Bootstrap 3, but Debian only shipped Bootstrap 2 at the time in a global package (they also changed the bootstrap 2 theme to use symlinks to the global version). How is this “better integration with the philosophy”?
> My software is a victim of Debian maintainers as well: they chose to remove the default theme from our static site generator, because it was built on top of Bootstrap 3, but Debian only shipped Bootstrap 2 at the time in a global package (they also changed the bootstrap 2 theme to use symlinks to the global version)
As a Debian stable devotee, this seems reasonable to me. If I wanted each package to bring along & manage its own dependencies, I'd use flatpaks.
> How is this “better integration with the philosophy”?
I'm guessing Bootstrap 3 wasn't yet in whatever release/channel your software was being packaged for?
Can't you imagine any possible benefits of not shipping bootstrap v2 and Bootstrap v3? Or do you just disagree with the Debian unstable -> testing -> stable philosophy? Dependency juggling is just one of the issues distro package maintainers have to wrangle with, that upstream maintainers typically don't care about - an upstream project can declare "this version requires the latest glibc", but distro packagers may have to patch around that because the latest version of glibc hasn't been through testing.
As a Debian stable devotee, this seems reasonable to me. If I wanted each package to bring along & manage its own dependencies, I'd use flatpaks.
> How is this “better integration with the philosophy”?
I'm guessing Bootstrap 3 wasn't yet in whatever release/channel your software was being packaged for?
Can't you imagine any possible benefits of not shipping bootstrap v2 and Bootstrap v3? Or do you just disagree with the Debian unstable -> testing -> stable philosophy? Dependency juggling is just one of the issues distro package maintainers have to wrangle with, that upstream maintainers typically don't care about - an upstream project can declare "this version requires the latest glibc", but distro packagers may have to patch around that because the latest version of glibc hasn't been through testing.
We ship a copy of bootstrap within our data files. They could just leave it as-is and have it working. Bootstrap is a CSS/JS library, there is no global /usr/lib to be concerned about.
> because it was built on top of Bootstrap 3, but Debian only shipped Bootstrap 2 at the time in a global package
> there is no global /usr/lib to be concerned about
Aside from possibly the path being different, which is of no concern, how can the 2 above sentences reconcile with each other?
> there is no global /usr/lib to be concerned about
Aside from possibly the path being different, which is of no concern, how can the 2 above sentences reconcile with each other?
It is trivial to make the Bootstrap 3 global package install into a different folder than Bootstrap 2. It isn’t so trivial for shared libraries without different sonames, for example.
Most of HN who've been around know what Bootstrap is (rip, old Twitter). The same rules apply whether your package dependencies are .css, .js or .so
I think one of the potentially bigger things that doesn't yet exist is an easy way for non-developers to build their own packages with whatever options they want. By easy I mean a GUI tool that works across the majority of projects out there, and on any distro.
> If that were was all there is to packaging - upstream developers could do the same job & have their CI/CD pipeline shoot out a .deb file.
That's what some users seem to want today. It's why both Flatpak and Snap exist with the goals of letting upstream developers just CI/CD spit out a "universal" package for Linux and getting a more "Mac-like" (or "Windows-like" if you prefer) install experience with less waiting for package maintainers to get around to publishing upstream changes.
Admittedly, Flatpak and Snap aren't universally beloved either, yet, but the balance of what the job for a distro's package maintainers should be is definitely in shift.
That's what some users seem to want today. It's why both Flatpak and Snap exist with the goals of letting upstream developers just CI/CD spit out a "universal" package for Linux and getting a more "Mac-like" (or "Windows-like" if you prefer) install experience with less waiting for package maintainers to get around to publishing upstream changes.
Admittedly, Flatpak and Snap aren't universally beloved either, yet, but the balance of what the job for a distro's package maintainers should be is definitely in shift.
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
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.
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.
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.
If a user wants to build a hardened copy, they are free to do that. Distros should provide a version with standard features that are expected by end users.
As a Debian user I like how Debian just includes the basics in the main package and provides optional extras if you want them. I'm not sure how other distros handle it the other way around -- if the main package includes everything the risk is naive users install packages that include functions they don't need that end up exposing security issues. The Debian approach provides a reduced attack surface out of the box and if I happen to need something more its easy to just apt search ${package_name} and see what other extensions are available and install these. I do this regularly for PHP modules for instance if some PHP code complains a certain module is not available. It may not be your cup of tea but this is the Debian approach, and it makes sense from the perspective of a defensive user like me to keep things simple.
I agree, it's also supremely obnoxious that upgrading a piece of software means losing a lot of functionality - unless the user knows s/he needs to replace the package with the -full version..
Wahey, isn't that what MS does with e.g. Outlook. Congrats Debian, you're reaching Microsoft's level!
Wahey, isn't that what MS does with e.g. Outlook. Congrats Debian, you're reaching Microsoft's level!
I agree that is unfortunate however I would argue the package should have been built that way in the first place. It's not the best thing to do now but better late than never. I wonder if the Debian maintainer would consider some sort of transactional package which brings in the new package if you had the original one installed. However, as someone who has used Keepass and did not realise it had all these extra functionalities, I think the assessment that most users will see no difference is ultimately closer to the truth than many people realise. I migrated away from Keepass specifically because I thought it had no network functions which makes all this drama especially ironic for a software that was marketed (at the time) as a password manager to keep on your own device and not someone else's machine.
This kind of thing is one of the reasons why we have different distros. For Debian, it's actually common to provide a "minimal" package plus one or more versions built with different feature flags.
You doubt that bug poster's "belief" that "most people want" that change?
Randomly messing with the code they package is the primary job of a debian packager. Which is how we get such great contributions from debian maintainers like the weak keys fiasco.
It can also work the other way around. When I install Apache on other distros I end up having to disable so many modules -- whereas the default Apache config in Debian is pretty watertight I never really have to mess around with modules. Likewise installing PHP only installs the core PHP module, you have to specifically install the extras. Other distros install everything including the kitchen sink. Needless to say, I'll take the Debian approach, warts and all.
demand? Perhaps if you are unhappy you should ask for a refund. I just can't get my head around this sort of entitlement.
What do you propose instead? Why should users always accept and agree with the Debian maintainers' choices, even if they're dumb and produce insecure software? Why should being a volunteer give you a get out of jail free card?
I propose request, rather than demand. If you don't agree with the maintainers choice and it is a legitimate issue, you could raise the issue with the Debian community and try to get some more support. Alternatively, suggest a fix that meets both requirements (such as a -full package).
There is no get out jail card here... just people volunteering their time, and a subset of users that feel they have some sort of entitlement. If I volunteer to pick up trash at my local park, would you demand that I pick up your garbage? No.. that would make you a jerk.
I'm an inactive Debian Maintainer and retired Ubuntu core dev, so perhaps my views are biased.. but I really think people should show these volunteers more respect.
There is no get out jail card here... just people volunteering their time, and a subset of users that feel they have some sort of entitlement. If I volunteer to pick up trash at my local park, would you demand that I pick up your garbage? No.. that would make you a jerk.
I'm an inactive Debian Maintainer and retired Ubuntu core dev, so perhaps my views are biased.. but I really think people should show these volunteers more respect.
>Sorry, why do maintainers owe us anything?
"they're doing it for free, no one owes you anything" is always the argument people make when someone does something reasonably dumb and they need to defend the maintainers/devs. They don't owe anyone anything, but people DO HAVE _REASONABLE_ expectations of them.
"they're doing it for free, no one owes you anything" is always the argument people make when someone does something reasonably dumb and they need to defend the maintainers/devs. They don't owe anyone anything, but people DO HAVE _REASONABLE_ expectations of them.
Package maintainer != Project maintainer.
In this instance the maintainer of the Debian package for KeePassXC has unilaterally made a choice.
In this instance the maintainer of the Debian package for KeePassXC has unilaterally made a choice.
Which is pretty much what all other Debian package maintainers do. For Debian users it's expected they ensure the software they are packaging fits in with the Debian way of doing things. This is what Debian users want -- if they wanted all packages 'nude' with no changes applied there are other distros e.g. Arch that are much better suited. I personally tried other distros which tries to package as close to upstream as possible, and I was pretty surprised by the poor upstream defaults of many packages and lack of useful utilities. E.g. Apache is so much better packaged by Debian -- it wasn't until I installed Apache in Arch that I realised many of the useful stuff I used in Debian was actually Debian-specific. Most packages in Debian come with very good defaults that my "setup" script (i.e. install/configure packages) for my Debian machine is literally <50 lines whereas for Arch it was something like 200 lines including due to having to reconfigure a lot of not-very-well-thought-out upstream defaults that Arch kept in place.
With Debian I expect sensible default configs, but not “we deleted a load of actual features”.
In this case it’s features that were patched out - not plugins or a mere config change.
In this case it’s features that were patched out - not plugins or a mere config change.
KeepassXC consider these options as "plugins", it's right there in their official documentation for the build options.
The Debian package wasn't shipping the correct default configuration in the first place, it's unfortunate but better late than never, and it's not like you can't switch to the keepassxc-full package.
The Debian package wasn't shipping the correct default configuration in the first place, it's unfortunate but better late than never, and it's not like you can't switch to the keepassxc-full package.
> KeepassXC consider these options as "plugins", it's right there in their official documentation for the build options.
The devs said they're not actually plugins, and that was quoted here hours before you commented.
The devs said they're not actually plugins, and that was quoted here hours before you commented.
The documentation should be updated to reflect this, because at this time
https://github.com/keepassxreboot/keepassxc/wiki/Building-Ke...
https://github.com/keepassxreboot/keepassxc/wiki/Building-Ke...
-DWITH_XC_ALL=[ON|OFF] Enable/Disable compiling all plugins above (default: OFF)
Which is in line with how many other Debian packages work which is again why I think this isn't really a big issue from the perspective of a Debian user. Most of the upset seem to be coming from users of other distros unfamiliar with the Debian approach to doing things. I do agree it's annoying that this wasn't done from Day 1, but better late than never.
[deleted]
If you claim to distribute application FooBar, you owe it to the authors of said application to actually distribute FooBar and not something else that was modified against their wishes. If you want to distribute a modified version, you should call it something other than FooBar.
You also owe it to your users to not mislead them by claiming that your modified version is actually the real FooBar.
You also owe it to your users to not mislead them by claiming that your modified version is actually the real FooBar.
I note elsewhere in this thread that all they did was disable an option from the upstream build script -- suggesting this is an acceptable option provided by upstream themselves? I think suggesting a rename is a bridge too far given even upstream provides a way to build the software without the extra functionality behind what sounds like a simple build option flag.
[deleted]
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.
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#iss...
> This is now our fourth bug report because of the decision to neuter the base KeePassXC package in Debian
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
Users should ideally report bugs to their distribution, not to upstream. The distribution package maintainer then does triage to determine if the issue is specific to the distribution package or should be forwarded upstream.
That's how it used to be in the past (and still is for enterprise distros because you might as well use the support contract you paid for). But lately users have gotten more savvy about talking to upstream directly, especially since more and more upstreams are now on easy-to-use websites like GitHub instead of mailing lists. That's still fine if users do their own diligence to ensure the issue is with upstream and not with the distribution package, but alas they don't all do that, leading to these spurious reports.
That's how it used to be in the past (and still is for enterprise distros because you might as well use the support contract you paid for). But lately users have gotten more savvy about talking to upstream directly, especially since more and more upstreams are now on easy-to-use websites like GitHub instead of mailing lists. That's still fine if users do their own diligence to ensure the issue is with upstream and not with the distribution package, but alas they don't all do that, leading to these spurious reports.
What’s your point? We all know why it’s happening. The reality is that it’s not to user expectations, which is bad.
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...
And I, as an end user, am absolutely fine with that, as a user of vim-nox package etc etc...
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.
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?
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?
My .vimrc is 8 lines. I learned not take the kitchen sink with me on holiday.
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.
vim-tiny is installed by default on debian (providing a vim command), and also has X removed.
Okay? Calling it keepassxc-tiny would also be fine. I think it's relevant that `apt install vim` does not give you vim-tiny.
Yeah, I hated that too.
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?
I'm one of those users. If I'm loud, does that mean my opinion doesn't count anymore?
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.
> 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.
They were. apt shows the NEWS file during update when there's a change.
I don't recall ever seeing that on Debian and derivatives.
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 :-<
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 :-<
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.
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.
Hyperbole!
$ apt install keepassx
$ apt install keepassx-full
Choice made.
$ apt install keepassx
$ apt install keepassx-full
Choice made.
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?
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
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
> 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.
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.
The default build of KeepassXC is without any optional modules
https://github.com/keepassxreboot/keepassxc/wiki/Building-Ke...
If KeepassXC is unhappy with the defaults, they can adjust theirs to reflect what they feel should be available out of the box.
https://github.com/keepassxreboot/keepassxc/wiki/Building-Ke...
-DWITH_XC_ALL=[ON|OFF] Enable/Disable compiling all plugins above (default: OFF)
If KeepassXC is unhappy with the defaults, they can adjust theirs to reflect what they feel should be available out of the box.
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.
Obligatory article, "I am 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.
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.
> 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.
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.
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.
By the same argument we should remove encryption as well, because it increases the amount of code and thus the attack surface.
>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."
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."
> 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?
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?
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.
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.
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.
> 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?
They can do that... under a name that doesn't mislead people. Is that so hard?
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.
I would be pissed if a FreeBSD package was some non-standard configuration.
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".
> 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".
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.
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.
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).
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.
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#iss... - that’s what I’m talking about.
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#iss... - that’s what I’m talking about.
What was your package named?
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.
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#iss...
EDIT: link to a KeeppassXC maintainer explaining that they're not plugins: https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
> changing the compile flag didn't remove the options that enable the features from the UI
Hopefully this will get fixed
Hopefully this will get fixed
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.
Like sure there is breakage, if you don't read the news before upgrading major versions.
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
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.
as others said, core functionality that UPSTREAM THEMSELVES decided not to include in default/recommended build instructions?
>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/INS...
1. https://github.com/keepassxreboot/keepassxc/blob/da90319d2d0...
2. https://github.com/keepassxreboot/keepassxc/blob/da90319d2d0...
3. https://github.com/keepassxreboot/keepassxc-packaging/blob/9...
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/INS...
1. https://github.com/keepassxreboot/keepassxc/blob/da90319d2d0...
2. https://github.com/keepassxreboot/keepassxc/blob/da90319d2d0...
3. https://github.com/keepassxreboot/keepassxc-packaging/blob/9...
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.
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.
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.
In this case, though, it's not even a patch - it's a build flag that is provided by upstream.
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.
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.
> 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.
Oh, the horror of being in unstable/testing channel and ignoring the change notice which has been shown automatically during apt-get upgrade.
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.
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.
> “it’s in the notes!”
Your words, not mine.
It isn't buried somewhere, it's in NEWS.Debian file, and it's shown to user during the package update by default.
Your words, not mine.
It isn't buried somewhere, it's in NEWS.Debian file, and it's shown to user during the package update by default.
Are you sure it was shown? I didn’t see one on Sid.
It's in NEWS.debian file [0], so apt-listchanges (which is installed by default in standard installation) should've shown it.
[0] https://salsa.debian.org/debian/keepassxc/-/blob/main/debian...
[0] https://salsa.debian.org/debian/keepassxc/-/blob/main/debian...
I've visited the App Store world, and my experience was that, weighted by how often packages appear in search results, the median is charitably described as "potentially unwanted", and honestly described as malware.
people did not have their pitchforks out for (although not exactly a cve thing) https://daniel.haxx.se/blog/2024/03/08/the-apple-curl-securi...
flipping build switches that upstream provided is "edited your app" ??
> 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.
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.
Oh no, xscreensaver or GNU Parallel flame war once again.
Isn't this just FOSS working as intended?
There are lots of distributions other than Debian.
There are lots of distributions other than Debian.
[deleted]
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
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.
> 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.
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.
> 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?
What are you talking about? This is an upstream build option. Has upstream forked itself by providing this option?
That seems entirely fair to me.
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 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
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 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
So the Debian maintainer complains about the upstream project (which they decided to maintain the package for) bringing "crap" and having "utterly misguided" development? And somehow people say that this is the reasonable person here, basing a major change of a software's featureset on such an opinion?
Independent from whether the original change is good or bad, so much of what's wrong with Open Source is people trying to work against each other instead of together...
Independent from whether the original change is good or bad, so much of what's wrong with Open Source is people trying to work against each other instead of together...
what leads you to suspect he's wrong? from the quotes in your comment i suspect it's his choice to use plain language and openly disagree with others. in my experience that's how trustworthy, competent people talk
people working together successfully in free software doesn't depend on them having the same values or getting along or wanting the software to do the same thing. it just depends on being clear and open about what the software does and doesn't do, and using licenses that keep them from suing you for distributing versions without their preferred features or antifeatures. remember that this is the movement that not only includes richard stallman but was founded by him. if it depended on getting along it never would have left the cradle
people working together successfully in free software doesn't depend on them having the same values or getting along or wanting the software to do the same thing. it just depends on being clear and open about what the software does and doesn't do, and using licenses that keep them from suing you for distributing versions without their preferred features or antifeatures. remember that this is the movement that not only includes richard stallman but was founded by him. if it depended on getting along it never would have left the cradle
I suspect he's wrong because he's disabled some of KeepassXC's most important security features.
One of the largest security threats to users is phishing websites, getting an email and clicking a link, and then typing your actual password into some fake hacker's webpage.
Having browser integration in your password manager, such that it auto-enters the right password on "real-bank.com", but doesn't enter it on "rel-bank.com", is a strong protection against phishing.
The maintainer disabled the browser integration for KeepassXC, which forces users to copy+paste passwords into webpage's password inputs, making them significantly more vulnerable to phishing.
Their fear-mongering about supply-chain attacks and bugs in more LoC is silly when compared to the very real threat of phishing attacks, which are way more prevalent and a way more severe threat.
One of the largest security threats to users is phishing websites, getting an email and clicking a link, and then typing your actual password into some fake hacker's webpage.
Having browser integration in your password manager, such that it auto-enters the right password on "real-bank.com", but doesn't enter it on "rel-bank.com", is a strong protection against phishing.
The maintainer disabled the browser integration for KeepassXC, which forces users to copy+paste passwords into webpage's password inputs, making them significantly more vulnerable to phishing.
Their fear-mongering about supply-chain attacks and bugs in more LoC is silly when compared to the very real threat of phishing attacks, which are way more prevalent and a way more severe threat.
I guess you missed the bits on Mastodon where the package maintainer simply didn’t bother reaching out to the upstream whatsoever because he was ‘too busy’ and would only do so over a particular IRC setup. That’s not competent or good faith maintenance.
The extra functionality isn't opening security holes. It is central functionality that users have come to expect such as Auto-Type or support for YubiKeys. The Debian maintainer has decided to disable the WITH_XC_ALL flag, which disables ALL optional features (not sure why you consider this a lie).
Your claim that KeePassXC communicates with random webpages is also false. There are two cases in which websites are communicated with (none of them random): a) an optional update check (can be disabled), b) when you click the button to download a website's favicon. Please don't just state things that are not true.
Your claim that KeePassXC communicates with random webpages is also false. There are two cases in which websites are communicated with (none of them random): a) an optional update check (can be disabled), b) when you click the button to download a website's favicon. Please don't just state things that are not true.
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?
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?
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
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
Looks like pretty reasonable decision to me - network features and browser integrations are huge potential holes / exploit entry points. And without network-related features and only running the trusted databases, the tool should be impossible to exploit even if exploits are found, which is a very desirable trait for something as important as password manager. Even original maintainer agrees [1].
Remember, the full network-enabled package is present in debian as well - so all the network features are "apt install keepassxc-full" away, for users that want it.
Two minor comments: calling your upstream "crappy"[0] is probably not the most productive way for package maintainer to act. Also, I am not sure if the package names (keepassxc vs keepassxc-full) are best for Debian users - something like keepassxc-lite and keepassxc-full might be more informative.
[0] https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
[1] https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
Remember, the full network-enabled package is present in debian as well - so all the network features are "apt install keepassxc-full" away, for users that want it.
Two minor comments: calling your upstream "crappy"[0] is probably not the most productive way for package maintainer to act. Also, I am not sure if the package names (keepassxc vs keepassxc-full) are best for Debian users - something like keepassxc-lite and keepassxc-full might be more informative.
[0] https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
[1] https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
Lots of things are a huge potential hole and/or exploit entry point. Lots of these things are also useful.
And "being useful" can increase security because if password managers are hard to use then people stop using them.
And looking at this a bit more, it's not clear to me that using the clipboard is necessarily more secure than the browser integration. Copy/paste accidents alone would offset quite a bit of the security footprint of a browser integration.
Many years ago I did some contracting for a fairly large company.[1] The laptops of their account managers had a disk encryption passwords, Windows login password, and AD login password. They all had to be different. They all had to be changed every few months. They all had "must contain at least two capitals, at least 4 non-letter/digits, and at least one 11 digit prime number"-type requirements.
Every single laptop I ever saw had a post-it note with all three passwords. Without exception.
My point here is: hypothetical security nerd security does not equal actual real-world security. Or at least not always. There are real trade-offs to be made here.
[1]: We did some maintenance of the laptops as an external contractor for some of the guys. They weren't really supposed to, but it was tons faster and easier because less bureaucracy, as doing it by their own IT system took forever. It was that type of company. This, on its own, was of course also a "security risk" because random tech guys from a computer store shouldn't really be on their laptops with super-secret company data (I don't think there wasn't that much to protect, other than sales/customer numbers which is only useful for a very select group of people).
And "being useful" can increase security because if password managers are hard to use then people stop using them.
And looking at this a bit more, it's not clear to me that using the clipboard is necessarily more secure than the browser integration. Copy/paste accidents alone would offset quite a bit of the security footprint of a browser integration.
Many years ago I did some contracting for a fairly large company.[1] The laptops of their account managers had a disk encryption passwords, Windows login password, and AD login password. They all had to be different. They all had to be changed every few months. They all had "must contain at least two capitals, at least 4 non-letter/digits, and at least one 11 digit prime number"-type requirements.
Every single laptop I ever saw had a post-it note with all three passwords. Without exception.
My point here is: hypothetical security nerd security does not equal actual real-world security. Or at least not always. There are real trade-offs to be made here.
[1]: We did some maintenance of the laptops as an external contractor for some of the guys. They weren't really supposed to, but it was tons faster and easier because less bureaucracy, as doing it by their own IT system took forever. It was that type of company. This, on its own, was of course also a "security risk" because random tech guys from a computer store shouldn't really be on their laptops with super-secret company data (I don't think there wasn't that much to protect, other than sales/customer numbers which is only useful for a very select group of people).
I fully agree with you.
I wish people would stop focusing heavily on how removing features can potentially decrease attacks.
Especially when those exact features are used to prevent the WORST possible attack vector, a mishandled or exploited Clipboard. I do not see how else would a user be able to gain access to the passwords without either using the keyboard, or opening the edit dialogue to select "show password" which would just make them plain-text and MUCH easier to attack.
These features were introduced to not only offer ease of use, but to facilitate a more secure method of transferring the password to the desired location.
These maintainers clearly did NOT think these things through and potentially created a much less secure package than intended.
There's one way in which browser integration improves security vs not using it, which is that the browser extension checks the page URL before filling in the credentials, while the approach of manually copy-pasting credentials is vulnerable to typo- and homoglyph-phishing.
This. So much this. I don't even understand how browser integrations are not universally thought as a core part of a password manager. With all the phishing that's going along, it's really the last line of defense.
Oh and I'm not only talking about elderly relatives and such. Modern phishings are very very well made, and there's one going on to steal Steam accounts that I would have likely fell for (and I consider myself pretty good on the matter).
Oh and I'm not only talking about elderly relatives and such. Modern phishings are very very well made, and there's one going on to steal Steam accounts that I would have likely fell for (and I consider myself pretty good on the matter).
I'm replying just to +1 this as well. This has saved me multiple times not from phishing attacks but from simple mistakes such as entering a password into a HTTP page when the website supports HTTPS.
Often I'm just browsing along and try to get KeepassXC to autofill a password only to be frustrated when it refuses to work. Then the frustration turns to relief when I go into KeepassXC and see that I've entered "https://website.com" into KeepassXC's URL box causing KeepassXC to only autofill the password on the HTTPS variant of the website and I was on the HTTP variant of the page.
Obviously it's best for the website to just setup HSTS, but I can't fix that for them.
I previously used auto-type and always thought browser extensions were insecure until I realized this.
Often I'm just browsing along and try to get KeepassXC to autofill a password only to be frustrated when it refuses to work. Then the frustration turns to relief when I go into KeepassXC and see that I've entered "https://website.com" into KeepassXC's URL box causing KeepassXC to only autofill the password on the HTTPS variant of the website and I was on the HTTP variant of the page.
Obviously it's best for the website to just setup HSTS, but I can't fix that for them.
I previously used auto-type and always thought browser extensions were insecure until I realized this.
It's not like the clipboard is secure either. Any arbitrary app can listen to the clipboard in X11, and while it seems harder in Wayland, I'm not sure if I've ever seen a clipboard permission dialog (my Wayland experience is limited though).
Turning off the browser intergation means that the user may accidentally auto-type into the wrong website. Turning off auto-type means that external applications can see the password.
Turning off the browser intergation means that the user may accidentally auto-type into the wrong website. Turning off auto-type means that external applications can see the password.
With Wayland, the compositor gets to decide which clients to send the "clipboard data available to paste from this file descriptor" event to (wl_data_offer). For example the compositor might only send it to the client whose window is currently focused. So clients that don't receive this event would not have the fd to be able to read from it. Clients that do receive the event can read that data without any restrictions.
That said, this ends up also making this like clipboard managers or wl-paste not work, so there is a wlroots protocol (wlr_data_control) that lets the client know about all data offers. How is a malicious process prevented from being a client of this interface (or even should a process be prevented...) depends on the compositor.
That said, this ends up also making this like clipboard managers or wl-paste not work, so there is a wlroots protocol (wlr_data_control) that lets the client know about all data offers. How is a malicious process prevented from being a client of this interface (or even should a process be prevented...) depends on the compositor.
[deleted]
This is essential to my own usage of KeepassXC. I never copy/paste from it into a browser and appreciate having this first line defense against phishing.
I agree that network features and browser integrations are huge potential holes, but the contributors on the GitHub issue make a very good point when they say that there's minimal testing of the stripped-down build in comparison with the full build, and no testing at all of random combinations of build flags.
As noted elsewhere, one of the "optional" flags that got disabled is yubikey support, without which users are getting locked out of their password manager when they upgrade to the new, broken package. Enabling just that flag puts the project in a state which nobody is actually testing.
I agree that calling the package keepassxc-lite would have prevented this issue, assuming existing users were moved to keepassxc-full, but that's the entire problem here! It's a reasonable choice to default to the most secure solution (not that hypothetical attack surface is a real vulnerability), but as a maintainer you shouldn't break existing functionality unless either upstream or your users want you to, and you particularly shouldn't lock users out of their password manager.
As noted elsewhere, one of the "optional" flags that got disabled is yubikey support, without which users are getting locked out of their password manager when they upgrade to the new, broken package. Enabling just that flag puts the project in a state which nobody is actually testing.
I agree that calling the package keepassxc-lite would have prevented this issue, assuming existing users were moved to keepassxc-full, but that's the entire problem here! It's a reasonable choice to default to the most secure solution (not that hypothetical attack surface is a real vulnerability), but as a maintainer you shouldn't break existing functionality unless either upstream or your users want you to, and you particularly shouldn't lock users out of their password manager.
> make a very good point when they say that there's minimal testing of the stripped-down build in comparison with the full build,
So they should be thankful their software will have better test coverage thanks to Debian users
So they should be thankful their software will have better test coverage thanks to Debian users
> calling your upstream "crappy"[0] is probably not the most productive way for package maintainer to act
This is so incredibly rude to post on the github it'd make me reconsider using Debian at all if I did. If the package is so full of "crappy" features why is he even bothering to maintain it? Just get rid of it and let users figure out how to install it properly themselves.
I feel bad for KeepassXC devs, maintaining an open source project is hard enough without having to deal with crap like this.
This is so incredibly rude to post on the github it'd make me reconsider using Debian at all if I did. If the package is so full of "crappy" features why is he even bothering to maintain it? Just get rid of it and let users figure out how to install it properly themselves.
I feel bad for KeepassXC devs, maintaining an open source project is hard enough without having to deal with crap like this.
TBF he's a canonical employee, not a debian employee, he's paid to maintain Ubuntu packages, but volunteers for the debian ones, so I'd be more side-eyeing Ubuntu first.
But then I gave up on debian a while ago because of some of their more questionable decisions.
But then I gave up on debian a while ago because of some of their more questionable decisions.
Interesting, what are some examples of questionable decisions?
Using the term crappy made me immediately lose respect for julian-klode.
Particularly of features that users depend on. It really leaves the impression that he thinks very little of debian users.
Features that according to your GP was disabled by default. And according to others in this discussion thread, disabled by default in the upstream also.
If you read the GitHub discussion these features are usually compiled in but not actually exercised until the user enabled then in the UI. The debian packager has changed the compile-time configuration to disable them at compile-time, making them unavailable to the user in the UI. Regardless of the makefile defaults this be a breaking change.
There is a some confusion because the flags that control these features at compile-time do default to OFF if not provided, but the installation instructions in the same documentation also tell you to compile with XC_ALL set to ON. The maintainers themselves talk about all features being enabled at compile-time in the discussion thread and even consider removing these compile-time flags altogether to prevent compiling keepassxc without these features. So "disabled by default" is not really an accurate understanding. It is clear that the intended configuration from the authors is for all features to be compiled in and available.
See: https://github.com/keepassxreboot/keepassxc/issues/10725#iss... https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
There is a some confusion because the flags that control these features at compile-time do default to OFF if not provided, but the installation instructions in the same documentation also tell you to compile with XC_ALL set to ON. The maintainers themselves talk about all features being enabled at compile-time in the discussion thread and even consider removing these compile-time flags altogether to prevent compiling keepassxc without these features. So "disabled by default" is not really an accurate understanding. It is clear that the intended configuration from the authors is for all features to be compiled in and available.
See: https://github.com/keepassxreboot/keepassxc/issues/10725#iss... https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
He removed not only networking but support for yubikey, and autotype.
These are all features that are turned off by default.
These are all features that are turned off by default.
> and autotype
I would go crazy w/o autotype. The way the IT dorks were forced by management to set up 'SSO' via an external provider at work, you have to enter the same information at least 3 times a day. 'SSO' for management means 'sign into each of our tools each single day'. Muh, no work done equals better security!
I would go crazy w/o autotype. The way the IT dorks were forced by management to set up 'SSO' via an external provider at work, you have to enter the same information at least 3 times a day. 'SSO' for management means 'sign into each of our tools each single day'. Muh, no work done equals better security!
I'm in info sec and I agree with you. cyberArk weekly password rotation, no ability to save passwords in Edge, no ability to install a password manager.
Guess who keeps their password saved in notepad, all but three characters?
Guess who keeps their password saved in notepad, all but three characters?
Usually SSO means that you have to login just once to access all of your accounts. If it requires you to login multiple times a day then something is not configured correctly.
Well... at my current employer, we have 3 "SSO" providers.
By that, I mean three different Okta logins, and logging in to any of them will log you out of the other two. If I want to do anything, it means I need to log in again because it is unlikely that I am logged in to the right account.
Yes, I need all 3 multiple times daily. There is no logic about which one I need for which system.
IT knows this is not how it is supposed to be, but they assure us that this is a temporary situation. I guess 1.5 Years is still temporary.
By that, I mean three different Okta logins, and logging in to any of them will log you out of the other two. If I want to do anything, it means I need to log in again because it is unlikely that I am logged in to the right account.
Yes, I need all 3 multiple times daily. There is no logic about which one I need for which system.
IT knows this is not how it is supposed to be, but they assure us that this is a temporary situation. I guess 1.5 Years is still temporary.
If you can use Firefox, it allows you to create multiple "containers", each with its own set of cookies and other state. You can create a separate container for each Okta login, then you can be logged into all three accounts simultaneously.
Also you can create a separate browser profile for each account. This works with all browsers but is less convenient, because it forces you to have a separate browser window for each profile, and also you need to enter all preferences for each profile separately.
Also you can create a separate browser profile for each account. This works with all browsers but is less convenient, because it forces you to have a separate browser window for each profile, and also you need to enter all preferences for each profile separately.
Can someone make a security related case for disabling autotype?
Yeah that makes no sense, if anything I'd keep autotype and prevent copy password
"If hit by mistake it might autotype in a window that is not at a login prompt, but maybe on a chat session and broadcast the user's password"
It's horseshit, but it's an argument
lets see what it does here...
NikkiA
edit: well, I guess it didn't broadcast the password, but it probably would have done on a real chat window that accepted multiple lines of input
It's horseshit, but it's an argument
lets see what it does here...
NikkiA
edit: well, I guess it didn't broadcast the password, but it probably would have done on a real chat window that accepted multiple lines of input
That's actually reasonable. I use keepassxc, and I have messed the autotype many times. But I mean, that is not an argument for disabling the feature.
If it's turned off by default, then please explain the drama. This simple statement makes this drama look like a storm in the proverbial teacup.
If I have both enabled in my install, which I specifically chose to, then upgrading the package locks me out of my database, because those features are not compiled.
Jeez, then you simply install the keepassxc-full package and move on. It's not like you store your sudo password in keepass database, too.
but that is part of the problem: this isn't clearly communicated to the end user in the future or present.
Current users will have their install broken and need to google to figure out what is going on.
Future users will install `keepassxc` thinking it would be actually KeePassXC before potentially realizing its a minimal version.
Personally I think splitting it into `keepassxc-full` and `keepassc-minimal` would be better since it moves the choice to the user instead of implying the contents.
Current users will have their install broken and need to google to figure out what is going on.
Future users will install `keepassxc` thinking it would be actually KeePassXC before potentially realizing its a minimal version.
Personally I think splitting it into `keepassxc-full` and `keepassc-minimal` would be better since it moves the choice to the user instead of implying the contents.
How more clearly do you expect it to be communicated?
apt shows the NEWS file during update when there's a change. If it doesn't (ie. user set it up to blindly do the upgrade), you can still check the news file or .debian.changelog.gz file afterwards.
And note that this happened in testing/sid channel, where breakage is supposed to be happen. When this change shipped in the new major Debian stable release in a few years, it'll surely be clearly written in the release notes.
What else do you expect, SMS notification? :P
If a user haven't seen the above he for sure won't see an announcement in a crowded debian-whatever-announce mailing list he isn't subscribed to or an obscure blog post posted somewhere he doesn't follow.
apt shows the NEWS file during update when there's a change. If it doesn't (ie. user set it up to blindly do the upgrade), you can still check the news file or .debian.changelog.gz file afterwards.
And note that this happened in testing/sid channel, where breakage is supposed to be happen. When this change shipped in the new major Debian stable release in a few years, it'll surely be clearly written in the release notes.
What else do you expect, SMS notification? :P
If a user haven't seen the above he for sure won't see an announcement in a crowded debian-whatever-announce mailing list he isn't subscribed to or an obscure blog post posted somewhere he doesn't follow.
I've almost never needed to read those news to keep the system working as I want it to. That's the thing.
How would you know in the first place
apt shows the NEWS file during update when there's a change.
If it doesn't (ie. you set it up to blindly do the upgrade), you can still check the news file or .debian.changelog.gz file afterwards.
Lastly, when it's shipped in the new major Debian stable release in a few years, it'll surely be noted in the release notes.
If it doesn't (ie. you set it up to blindly do the upgrade), you can still check the news file or .debian.changelog.gz file afterwards.
Lastly, when it's shipped in the new major Debian stable release in a few years, it'll surely be noted in the release notes.
They are not "features that are turned off by default" but plugins that are now actually plugins and not built-in features that are turned off. Why on earth would they include plugins that aren't plugged in as a default?
How anyone could see a smaller attack surface as a bad thing on HN baffles the mind. Could he have made a -minimal version? Sure, but the default version should be the clean, secure, without plugins version so he did the right thing.
How anyone could see a smaller attack surface as a bad thing on HN baffles the mind. Could he have made a -minimal version? Sure, but the default version should be the clean, secure, without plugins version so he did the right thing.
>How anyone could see a smaller attack surface as a bad thing on HN baffles the mind.
Because in the real world, with real users, you must balance security and friction. If you have too much friction, users look for workarounds and your theoretical security increase becomes a real world security decrease.
For a real world example of this phenomenon, see forced arbitrary password changes (which are now universally discouraged). They are theoretically more secure, but study after study has proven that, in the real world, forced arbitrary password changes reduce organization-wide security.
Security requires a holistic approach. Users and their behaviors are part of that. Looking only at attack surface is a sure-fire way to make your users work against your security policies rather than with.
Because in the real world, with real users, you must balance security and friction. If you have too much friction, users look for workarounds and your theoretical security increase becomes a real world security decrease.
For a real world example of this phenomenon, see forced arbitrary password changes (which are now universally discouraged). They are theoretically more secure, but study after study has proven that, in the real world, forced arbitrary password changes reduce organization-wide security.
Security requires a holistic approach. Users and their behaviors are part of that. Looking only at attack surface is a sure-fire way to make your users work against your security policies rather than with.
Why does everyone keep using this word "plugins"? Quoting the developer:
> 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.
> 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.
[deleted]
> How anyone could see a smaller attack surface as a bad thing on HN baffles the mind.
Because if it removes features many (perhaps even most) people use then that makes it less useful. And potentially insecure as people will stop using KeePassXC and replace it with "passw0rd123", because "I really need to get this done now, and not fuck about with KeePassXC not working". Is there even a message? Or any indication in the UI what's going on? I don't think there is.
Here's what should have happened if you really think that "keepassxc" package should install a minimal version: contact maintainers of KeePassXC, discuss best way to do this, maybe allow them some time to create better UX on this. Maybe create a PR or two. And then change your package. That Debian bug was 4 years old – it could have waited a month or two more.
You're also far too hung up on the word "plugin". That word has tons of meanings, and the original meaning of "something optional I can add (plug in) later on" doesn't really apply here.
Because if it removes features many (perhaps even most) people use then that makes it less useful. And potentially insecure as people will stop using KeePassXC and replace it with "passw0rd123", because "I really need to get this done now, and not fuck about with KeePassXC not working". Is there even a message? Or any indication in the UI what's going on? I don't think there is.
Here's what should have happened if you really think that "keepassxc" package should install a minimal version: contact maintainers of KeePassXC, discuss best way to do this, maybe allow them some time to create better UX on this. Maybe create a PR or two. And then change your package. That Debian bug was 4 years old – it could have waited a month or two more.
You're also far too hung up on the word "plugin". That word has tons of meanings, and the original meaning of "something optional I can add (plug in) later on" doesn't really apply here.
Compile-time flags are by definition not plugins. All optional features were removed indiscriminately.
Your conflating PLUG IN technical term with PLUG IN from a users perspective.
No one was really friends with tom on myspace.
No one was really friends with tom on myspace.
I see this kind of mindset often--if we remove the features useful but not perfectly secure from users, we can protect them from such insecurity. But this mindset is wrong. What happens instead is that users will fulfill their needs in even more insecure ways.
Which more insecure ways? At worst they can install the keepassxc-full package and back to exactly where they were. This isn't tyranny, maintainer has provided a choice.
I'm not sure I really agree here. If there's fundamental concern for the security of a software package, why package the software?
What's stopping a malicious actor from including malicious network code outside of the compile flags?
What's stopping a malicious actor from including malicious network code outside of the compile flags?
The concern here is accidentally vulnerable code, not malicious code.
Intentionally malicious or accidentally vulnerable, vulnerable code is vulnerable code.
Disabling compile flags on functionality doesn't necessarily guarantee you're any more secure, especially if the software isn't regularly tested without those flags.
Disabling compile flags on functionality doesn't necessarily guarantee you're any more secure, especially if the software isn't regularly tested without those flags.
Sure it does.
If the software (1) only ever used on trusted data (2) never makes network requests, then even with most vulnerable libraries, it simply cannot be exploited. But features like "fetch favicon from untrusted websites" open huge security holes in case there are ever bugs in http or image libraries.
(note that in case of local compromise, it does not matter if keepass is secure or not - the attacker can install keylogger, inject code into process or replace it altogether)
If the software (1) only ever used on trusted data (2) never makes network requests, then even with most vulnerable libraries, it simply cannot be exploited. But features like "fetch favicon from untrusted websites" open huge security holes in case there are ever bugs in http or image libraries.
(note that in case of local compromise, it does not matter if keepass is secure or not - the attacker can install keylogger, inject code into process or replace it altogether)
> If the software (1) only ever used on trusted data (2) never makes network requests, then even with most vulnerable libraries, it simply cannot be exploited.
You're assuming the flags remove all of the whats-deemed-as-risky behavior.
Trusting the flags from the lens of wanting to trim down a package size? Reasonable.
Trusting the flags from the lens of wanting to boost security? Eh... Crafting a security policy based on compile flags requires a lot of trust towards the developer of the code or spending a lot of time auditing these compile flags.
I just don't see the logic in wanting to simultaneously avoid trusting the code while also placing an enormous amount of new trust in the code's post-compile behavior.
> But features like "fetch favicon from untrusted websites" open huge security holes in case there are ever bugs in http or image libraries.
Image support is still built in, though. You're still susceptible to the vulnerable image library. Just because you're now pulling the images by hand doesn't make it any more secure.
With these concerns users should be considering some form of sandboxing. Whether it's tossing the package in a network-restricted container, VM, or separate device. This is very close to dogmatic security theater.
You're assuming the flags remove all of the whats-deemed-as-risky behavior.
Trusting the flags from the lens of wanting to trim down a package size? Reasonable.
Trusting the flags from the lens of wanting to boost security? Eh... Crafting a security policy based on compile flags requires a lot of trust towards the developer of the code or spending a lot of time auditing these compile flags.
I just don't see the logic in wanting to simultaneously avoid trusting the code while also placing an enormous amount of new trust in the code's post-compile behavior.
> But features like "fetch favicon from untrusted websites" open huge security holes in case there are ever bugs in http or image libraries.
Image support is still built in, though. You're still susceptible to the vulnerable image library. Just because you're now pulling the images by hand doesn't make it any more secure.
With these concerns users should be considering some form of sandboxing. Whether it's tossing the package in a network-restricted container, VM, or separate device. This is very close to dogmatic security theater.
I am not worried about xz-style intentional backdoors.
I am worried about unintentional bugs which end up being remotely exploitable.
So while making sure the image library is bug-free is practically impossible, it is pretty easy to check for compile-time feature flags. Build it once, then ldd to make sure the http library is not linked. Or check debug messages. Or objdump and make sure method is missing. Tons of very simple methods.
From this standpoint, disabling favicon fetching is a 100% effective mitigation for all remote attacks. I've never bothered uploading favicons by hand, and I've never needed any images in my notes.
No security theater, just a pragmatic view.
I am worried about unintentional bugs which end up being remotely exploitable.
So while making sure the image library is bug-free is practically impossible, it is pretty easy to check for compile-time feature flags. Build it once, then ldd to make sure the http library is not linked. Or check debug messages. Or objdump and make sure method is missing. Tons of very simple methods.
From this standpoint, disabling favicon fetching is a 100% effective mitigation for all remote attacks. I've never bothered uploading favicons by hand, and I've never needed any images in my notes.
No security theater, just a pragmatic view.
Yet how many people are checking what libraries are being linked on every compilation?
CMakefiles are susceptible to bugs too. KeepassXC could also very well remove these build flags and people would be none the wiser.
As I said, concerned users should look at other ways to isolate the application’s behavior here instead of relying on the build process.
Run it in an isolated network namespace if network connectivity is the prevailing concern.
CMakefiles are susceptible to bugs too. KeepassXC could also very well remove these build flags and people would be none the wiser.
As I said, concerned users should look at other ways to isolate the application’s behavior here instead of relying on the build process.
Run it in an isolated network namespace if network connectivity is the prevailing concern.
Indeed. I use Gentoo and one of the best things is being able to easily switch off features in individual packages like this (or across the whole system, like systemd or X11, for example). But what can a Debian user do? If they're going to build one binary and make it the default it should be the most secure version, not the most featureful.
The keepassxc account is being ridiculously sensationalist. Removing ALL features? Lol
The keepassxc account is being ridiculously sensationalist. Removing ALL features? Lol
Whouldn't be less surprising to publish full app as keepassxc and the other packages be named as -localonly or -partial or -secured or -local-and-secured ?
I think the solution suggested by drawks seems clearly the correct choice:
> I think the proper solution would probably be to package both a "-full" and "-minimal" version of the software and utilize Debian package meta-data fields to define a Conflicts relationship between the packages and tag them also both with a Provides for keepassxc and also add a tag Replaces: keepassxc to the -full build so that during a package upgrade an existing user would be provided the version that continues to provide the features of the package which is being upgraded/replaced while new users can choose for themselves which of the versions they'd like to install
https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
Why would this _not_ be the obvious choice?
> I think the proper solution would probably be to package both a "-full" and "-minimal" version of the software and utilize Debian package meta-data fields to define a Conflicts relationship between the packages and tag them also both with a Provides for keepassxc and also add a tag Replaces: keepassxc to the -full build so that during a package upgrade an existing user would be provided the version that continues to provide the features of the package which is being upgraded/replaced while new users can choose for themselves which of the versions they'd like to install
https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
Why would this _not_ be the obvious choice?
Because maintainers have an opinion and explicitly wanted to change the default.
Perhaps, and that's not unreasonable in and of itself. But to do so in such a user-hostile manner? That's a bit over the top. A new minimal package, advertising it, and only then eventually making it the default would have been far, far more effective.
If an engineer of mine pulled this on our user-base I'd have them reverting it in a heartbeat regardless of the technical merit. They already failed just in how they executed this and have burned good will, the technical merits no longer matter. Once you've lost the faith and trust of the user, it's over.
The original request[0] was more or less simply a user asking for the networking to be removed, and follow-up to just have a -nonetwork variation. Instead, we have comments from the debian maintainer:
The OP report: > Users who need this crap can install the crappy version but obviously this increases the risk of drive-by contributor attacks.
The debian package description[1]: > See keepassxc-full if you absolutely need those.
The PR[2] > Feature creep like SSH agent support, browser integration, Freedesktop.org secret storage, KeeShare pose undue risks for most users.
Each one of these sends a message. And it was entirely avoidable with a bit of grace and kindness to the existing userbase.
[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529
[1]: https://packages.debian.org/sid/keepassxc
[2]: https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f...
If an engineer of mine pulled this on our user-base I'd have them reverting it in a heartbeat regardless of the technical merit. They already failed just in how they executed this and have burned good will, the technical merits no longer matter. Once you've lost the faith and trust of the user, it's over.
The original request[0] was more or less simply a user asking for the networking to be removed, and follow-up to just have a -nonetwork variation. Instead, we have comments from the debian maintainer:
The OP report: > Users who need this crap can install the crappy version but obviously this increases the risk of drive-by contributor attacks.
The debian package description[1]: > See keepassxc-full if you absolutely need those.
The PR[2] > Feature creep like SSH agent support, browser integration, Freedesktop.org secret storage, KeeShare pose undue risks for most users.
Each one of these sends a message. And it was entirely avoidable with a bit of grace and kindness to the existing userbase.
[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529
[1]: https://packages.debian.org/sid/keepassxc
[2]: https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f...
Yeah, I agree with you. I'm joking that KeePassXC developers should make parsing .kdbx an optional feature (that's an attack surface by itself for sure!) and see whether Debian package maintainer enable it or not.
> user-hostile manner
This isn't user hostile.
You know what'd be user hostile? Removing the functionality and not providing the -full package alongside.
This isn't user hostile.
You know what'd be user hostile? Removing the functionality and not providing the -full package alongside.
It is.
The software has been broken - the UI wasn’t designed with those toggles in mind so now users suddenly have non functioning features presented to the in the UI.
The argument the all users should be keeping up to speed on NEWS - especially in the stable channels this will end up in - to explain why their UX is suddenly broken is not exactly ‘user friendly’.
The software has been broken - the UI wasn’t designed with those toggles in mind so now users suddenly have non functioning features presented to the in the UI.
The argument the all users should be keeping up to speed on NEWS - especially in the stable channels this will end up in - to explain why their UX is suddenly broken is not exactly ‘user friendly’.
> all users should be keeping up to speed on NEWS
They don't need to, it is shown to them during apt-get upgrade
> especially in the stable channels
This is in testing/unstable. Stable users aren't and won't be affected until until the next major Debian version is released and the users decides to do the upgrade.
They don't need to, it is shown to them during apt-get upgrade
> especially in the stable channels
This is in testing/unstable. Stable users aren't and won't be affected until until the next major Debian version is released and the users decides to do the upgrade.
That does allow you to change the default for users installing the packages and while ensuring that users who already have it installed don't lose functionality during an upgrade.
It not only _is_ the obvious choice, it is _exactly_ what has actually happened in Debian: https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f...
The original post is just a badly written clickbait. Nothing was removed, it was just moved to the keepassxc-full package.
The original post is just a badly written clickbait. Nothing was removed, it was just moved to the keepassxc-full package.
I don't believe you're correct. It seems like the option that Debian decided on _will_ remove those features for users who are upgrading a package.
Users who already have the keypassxc package will need to explicitly switch packages if they want the full one. That's not the same behaviour as described in my quote comment.
Users who already have the keypassxc package will need to explicitly switch packages if they want the full one. That's not the same behaviour as described in my quote comment.
Right, I should have been more careful with the word "exactly". I don't think the proposed solution can be implemented, though.
If the "keepassxc" package is to be replaced by the two alternatives ("keepassxc-full" and "keepassxc-minimal"), you'd still need a transitional dummy package named "keepassxc". That package would depend on "keepassxc-full | keepassxc-minimal", giving the user a choice to satisfy the dependency by installing either of those. So far so good. What if the user doesn't explicitly choose, though? The idea is that an upgrade would keep the "-full" variant but "apt install keepassxc" would pull in the "-minimal" variant. How do you encode this in Debian package metadata?
I think both "apt install" and "apt full-upgrade" will simply choose the first alternative, so you get either "-full" in both scenarios, or "-minimal" in both.
If the "keepassxc" package is to be replaced by the two alternatives ("keepassxc-full" and "keepassxc-minimal"), you'd still need a transitional dummy package named "keepassxc". That package would depend on "keepassxc-full | keepassxc-minimal", giving the user a choice to satisfy the dependency by installing either of those. So far so good. What if the user doesn't explicitly choose, though? The idea is that an upgrade would keep the "-full" variant but "apt install keepassxc" would pull in the "-minimal" variant. How do you encode this in Debian package metadata?
I think both "apt install" and "apt full-upgrade" will simply choose the first alternative, so you get either "-full" in both scenarios, or "-minimal" in both.
Meanwhile in Arch land (possibly other distros as well), the fwupd package (which I imagine to be a fairly common package to be installed among the user base) has been silently configured to depend on passim, which spins up an open web server on 0.0.0.0:27500[1] without any(!) explicit user consent whatsover. Passim then uses GnuTLS, which is famous for containing more holes than Swiss cheese [2][3].
Absolutely insane to me, and I would not be surprised if there's an xz type of exploit hidden somewhere in the chain.
[1]: https://github.com/fwupd/fwupd/issues/6721
[2]: https://news.ycombinator.com/item?id=7347500
[3]: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=gnutls
Absolutely insane to me, and I would not be surprised if there's an xz type of exploit hidden somewhere in the chain.
[1]: https://github.com/fwupd/fwupd/issues/6721
[2]: https://news.ycombinator.com/item?id=7347500
[3]: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=gnutls
why fish for fwupd? systemd-resolved which is everywhere, will open (at request) an LLMNR server (a.k.a. mDNS, nee microsoft netbios) on port 5355.
With IoT everyone have access to your LAN, so now people are making sure linux also join the REDACTED party
btw, fix for fwupmdg, since they have a low quality default conf file without commented out defaults:
With IoT everyone have access to your LAN, so now people are making sure linux also join the REDACTED party
btw, fix for fwupmdg, since they have a low quality default conf file without commented out defaults:
```
# /etc/fwupd/fwupd.conf
[fwupd]
P2pPolicy=none
```
```
# /etc/systemd/resolved.conf
[Resolve]
DNS=9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net
FallbackDNS=127.0.0.1 ::1
Domains=~.
DNSOverTLS=yes
LLMNR=no
DNSStubListener=no
```> mDNS, nee microsoft netbios
veering offtopic: I always thought mDNS was an Apple thing, since Bonjour is the most extensive implementation of it (and Windows sucks at it. In fact the only way I found to get a full mDNS implementation on Windows a few years ago was to install Bonjour via an installer extracted from iTunes for Windows).
The Wikipedia page for mDNS [1] doesn't have a lot of history information, saying just that the idea of mDNS was first proposed by Bill Woodcock & Bill Manning to the IETF in 2000, and neither seem obviously tied to Microsoft. Apple later published Bonjour in 2002, and mDNS only became an official rfc6762 in 2013!
[1] https://en.wikipedia.org/wiki/Multicast_DNS
veering offtopic: I always thought mDNS was an Apple thing, since Bonjour is the most extensive implementation of it (and Windows sucks at it. In fact the only way I found to get a full mDNS implementation on Windows a few years ago was to install Bonjour via an installer extracted from iTunes for Windows).
The Wikipedia page for mDNS [1] doesn't have a lot of history information, saying just that the idea of mDNS was first proposed by Bill Woodcock & Bill Manning to the IETF in 2000, and neither seem obviously tied to Microsoft. Apple later published Bonjour in 2002, and mDNS only became an official rfc6762 in 2013!
[1] https://en.wikipedia.org/wiki/Multicast_DNS
Because the history is not linear. See https://techcommunity.microsoft.com/t5/networking-blog/align...
it goes like this:
1. MS uses netBios.
2. apple uses bounjour, similar to netbios, but with modern conveniences, like NAT aware.
3. windows add same niceties on top of netbios and call it LLMNR.
4. apple standardize bounjour as mDNS and open it up just because they would have to publish code because of some licenses they offended (but going into this is veering way too much offtopic on your offtopic)
5. everyone standardize on mDNS
6. RedHat (using their fake open source promotion called freedesktop, nee XDG) pushes for LLMNR for god knows why! (well, might be a reason poetering works for MS now)
7. even microsoft abandon LLMNR and netbios in favour of mDNS. everyone is using mDNS. RH/freedesktop/systemd/fwmg (all the same people) chose to base their LAN distribution service logic on LLMNR.
8. RedHat works backward compatibility of LLMNR into mDNS and things get VERY confusing. Or not. Their documentation uses the name interchangeably and honestly, at this point I am not sure of anything and I'm not paid to look at that code for over a year. I wouldn't be surprised if resolved is actually using mDNS but the setting/code is still just "called" LLMNR. /shrug.
it goes like this:
1. MS uses netBios.
2. apple uses bounjour, similar to netbios, but with modern conveniences, like NAT aware.
3. windows add same niceties on top of netbios and call it LLMNR.
4. apple standardize bounjour as mDNS and open it up just because they would have to publish code because of some licenses they offended (but going into this is veering way too much offtopic on your offtopic)
5. everyone standardize on mDNS
6. RedHat (using their fake open source promotion called freedesktop, nee XDG) pushes for LLMNR for god knows why! (well, might be a reason poetering works for MS now)
7. even microsoft abandon LLMNR and netbios in favour of mDNS. everyone is using mDNS. RH/freedesktop/systemd/fwmg (all the same people) chose to base their LAN distribution service logic on LLMNR.
8. RedHat works backward compatibility of LLMNR into mDNS and things get VERY confusing. Or not. Their documentation uses the name interchangeably and honestly, at this point I am not sure of anything and I'm not paid to look at that code for over a year. I wouldn't be surprised if resolved is actually using mDNS but the setting/code is still just "called" LLMNR. /shrug.
Thank you, Internet stranger. This LLMNR/mDNS dichotomy has been on the back of my mind for quite some time. You've made it clear.
ur welcome. parts of it are in the zero conf wikipedia page btw.
looking at the fwupmgr code.
The client uses DBUS to ask the server how many bytes were download from your LAN peers (unless you connect your device directly to the internet, then i guess i will show how many bytes ssh probes downloaded from you, inflating their numbers and making them more aggressive on the server feature)
https://github.com/hughsie/passim/blob/ae38c13da1a63fff8c8fa...
https://github.com/hughsie/passim/blob/ae38c13da1a63fff8c8fa...
also, note the quaint code to tell how much carbon it saved earth.
edit: interestingly, if you search for that data collection method name, both ddg and google only find the call from fwmgr side. the actual one, older, from passim code is not shown anywhere
https://duckduckgo.com/?q="passim_client_get_download_saving...
but it's there https://github.com/hughsie/passim/blob/ae38c13da1a63fff8c8fa...
The client uses DBUS to ask the server how many bytes were download from your LAN peers (unless you connect your device directly to the internet, then i guess i will show how many bytes ssh probes downloaded from you, inflating their numbers and making them more aggressive on the server feature)
https://github.com/hughsie/passim/blob/ae38c13da1a63fff8c8fa...
https://github.com/hughsie/passim/blob/ae38c13da1a63fff8c8fa...
also, note the quaint code to tell how much carbon it saved earth.
edit: interestingly, if you search for that data collection method name, both ddg and google only find the call from fwmgr side. the actual one, older, from passim code is not shown anywhere
https://duckduckgo.com/?q="passim_client_get_download_saving...
but it's there https://github.com/hughsie/passim/blob/ae38c13da1a63fff8c8fa...
> since they have a low quality default conf file without commented out defaults
Try `man fwupd.conf` for all the options.
Try `man fwupd.conf` for all the options.
Good to know. I think this should probably be it's own post
I would like to believe package maintainers should operate under a principle of least astonishment and not disable core features (and not plugins, despite currently 25 entries of that word in this comment section) unless there's a documented or at the very least probable risk, none of which seem to be the case here. KeePassXC has many features but none that would on their own, and without explicit user intervention, be a likely source of vulnerabilities. The browser integration must be toggled on before you can even set it up, likewise for (I believe) every other function disabled with this flag, so a -minimal package may have been more appropriate. The small subset of users that could benefit in some indeterminate future from this change must be incredibly small, while it's going to be a serious annoyance for anyone using the browser integration, a function that's generally far safer than clipboard access. It also doesn't feel in line with the project's vision:
Our goal is to create an application that can be used by anyone while still offering advanced features to those that need them.
Our goal is to create an application that can be used by anyone while still offering advanced features to those that need them.
Considering it would be completely possible to make this distinction without breaking existing users, it's difficult to see this as anything other than a bad decision by the Debian package maintainer. While having the ability to have KeepassXC without networking features is certainly nice, considering the browser integration to be a niche feature is just severely out of touch; I would be willing to place real money on betting that more than half (probably well over half) of users of KeepassXC in Debian today want features that will be surprise-disabled because the maintainer chose a way of doing this that would break existing users to impose their opinion.
It is ultimately their decision to make, but that doesn't mean it is a good one, I contend it is not.
It is ultimately their decision to make, but that doesn't mean it is a good one, I contend it is not.
From a KeePassXC maintainer:
> In the lead up to this thread I received three reports of this new package method crippling people's workflow. One report was a user who couldn't open their database anymore because the yubikey feature was removed. Let that sink in for a second. People who lose access to their most important secrets can sometimes do irrational things in the moment of panic.
https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
> In the lead up to this thread I received three reports of this new package method crippling people's workflow. One report was a user who couldn't open their database anymore because the yubikey feature was removed. Let that sink in for a second. People who lose access to their most important secrets can sometimes do irrational things in the moment of panic.
https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
Everyone using an offline password manager without having a backup might as well consider everything lost
This sounds like emotional blackmail
How many times I lost everything, hardware failure, updates that broke OS, using dd in the wrong drive...
This sounds like emotional blackmail
How many times I lost everything, hardware failure, updates that broke OS, using dd in the wrong drive...
How would a backup help in this scenario? The data is fine, it's the application that stopped working.
If the yubikey stops working, you also loose access to the database
So I would have a backup with a simple password, or even unencrypted in a USB somewhere
So I would have a backup with a simple password, or even unencrypted in a USB somewhere
You backup the yubikey seed (whatever it's called) separately from the password db, so that the attacker still has to get 3 separate pieces of information (db, password, seed) to get the full access.
If you backup the "seed" hotp secret you can probably use any OTP client software to open the DB without needing the yubikey
What you usually do with YubiKeys is have multiple of them so that if the key stops working or you lose it you can use the spare.
This is more secure than using a simple password or (gasp) an unencrypted copy somewhere.
This is more secure than using a simple password or (gasp) an unencrypted copy somewhere.
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 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)
The WITH_XC_NETWORKING build option is off by default so the developers have obviously intended this to be a valid build configuration.
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!)
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!)
>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.
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.
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.
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.
> 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.
BS. This change was in Debian sid/testing. That's what it's for. Debian stable users' workflow hasn't been broken.
> 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.
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.
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.
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]
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.
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.
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".
So you shouldn't have "keepassxc" and "keepassxc-full". Instead you should have "keepassxc" and "keepassxc-minimal".
But it’s a valid build configuration option provided by upstream. Not sure I follow this line of reasoning.
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#iss...
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#iss...
The default package should be named keepassxc-debian-limited or similar and the proper package should be keepassxc
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.
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.
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.
> 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.
> 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".
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".
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.
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".
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".
What's the alternative to Debian / Ubuntu now that CentOS is gone?
It really depends on your usecase; I'm personally fond of OpenSUSE and Alpine Linux. OpenSUSE is more "conventional" like Debian/RHEL, and Alpine is a touch idiosyncratic (mostly, musl as its libc means 3rd-party binaries often won't work) but is tiny ant fantastic when it does work for your usecase.
Arch Linux and Void Linux are both worth a look I'd say.
Rolling-release distros are unlikely to fit into the same usecase as a slow-moving stable-release distro.
I believe the zoomer response to this is "bruh"
AlmaLinux and Rocky Linux are continuations of CentOS; I have no experience with either but that would be the logical place to start.
Fedora
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.
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.
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.
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).
For folks interested this issue on GitHub seems to have the latest comments.
https://github.com/keepassxreboot/keepassxc/issues/10725
https://github.com/keepassxreboot/keepassxc/issues/10725
Debian maintainer, Julian Klode, has a "pointed" opinion:
> I'm afraid that's not going to happen. It was a mistake to ship with all plugins built by default. This will be painful for a year as users annoyingly do not read the NEWS files they should be reading but there's little that can be done about that.
> It is our responsibility to our users to provide them the most secure option possible as the default. All of these features are superfluous and do not really belong in a local password database manager, these developments are all utterly misguided.
> Users who need this crap can install the crappy version but obviously this increases the risk of drive-by contributor attacks.
> I'm afraid that's not going to happen. It was a mistake to ship with all plugins built by default. This will be painful for a year as users annoyingly do not read the NEWS files they should be reading but there's little that can be done about that.
> It is our responsibility to our users to provide them the most secure option possible as the default. All of these features are superfluous and do not really belong in a local password database manager, these developments are all utterly misguided.
> Users who need this crap can install the crappy version but obviously this increases the risk of drive-by contributor attacks.
> I'm afraid that's not going to happen. It was a mistake to ship with all plugins built by default. This will be painful for a year as users annoyingly do not read the NEWS files they should be reading but there's little that can be done about that.
I deal with enough packages in my life that do massively breaking changes in point releases though, to be honest. This is reminding me of the good days that `apt upgrade` would uninstall the X-Server because nvidia fucked up their stuff.
Debian is kinda one of the places I expected to be better, and usually it does. (EDIT - And I guess the fact that this is causing a ruckus in testing is an indication of that. lets see how it develops.)
I deal with enough packages in my life that do massively breaking changes in point releases though, to be honest. This is reminding me of the good days that `apt upgrade` would uninstall the X-Server because nvidia fucked up their stuff.
Debian is kinda one of the places I expected to be better, and usually it does. (EDIT - And I guess the fact that this is causing a ruckus in testing is an indication of that. lets see how it develops.)
You don't have to proactively read it. But when you notice your keepassxc doesn't work as it used to before, that should be a trigger for you to go back and read it, note that it tells you very clearly that the functionality you're missing is now in keepassxc-full, apt-install it, and go on with your life.
One doesn't expect such a drastic ... 'fix' in a point release though.
You're talking as if it's a point release of Debian. It is not. It happened in sid/testing, that's what these releases are for.
Whether it happened in a point or major release of Keepassxc is irrelevant, because ignorant users who upgrade their sid/testing installations blindly as if it was stable-security would have hit it eventually.
Whether it happened in a point or major release of Keepassxc is irrelevant, because ignorant users who upgrade their sid/testing installations blindly as if it was stable-security would have hit it eventually.
IMO insisting on a change like this would require retiring the original, un-suffixed name. And making separate -min and -full packages instead.
I laughed when I saw this. I once tried to be a hit and run contributor to a project he maintains and I found him to be rude. He is still at it it seems.
That is an absolutely mental stance - effective asserting that he knows better than both the developers and users of a piece of software what features it should have! Promote this man to the Debian technical committee immediately, he's perfect.
lupusreal(2)
Title is wrong. The original post said maintainer has removed ALL features, not only networking features, and this was true, ALL optional features, including entirely offline features, were turned off during build.
Horrid PR for Debian. The decision is ignorant and capricious and makes Debian seem like a personal toy project instead of a FOSS cornerstone. On top of that the Debian maintainer then responds by calling upstream "crappy".
Said maintainer also does dev work for Canonical. So this probably affects optics for Ubuntu too. Although, speculating charitably, maybe the maintainer knows something we don't about the upstream's security policies.
Debian maintainers are experts at touching things they shouldn't and creating a mess in the process. The worst case, by far, was when they broke the RNG of SSH key generation:
https://jblevins.org/log/ssh-vulnkey#:~:text=In%20May%202008....
Those guys are out of control and constantly having conflicts with upstream, I'm astounded to see the amount of support I see for debian in this thread.
https://jblevins.org/log/ssh-vulnkey#:~:text=In%20May%202008....
Those guys are out of control and constantly having conflicts with upstream, I'm astounded to see the amount of support I see for debian in this thread.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529
I don't think the Debian maintainer is aware that the favicon download feature is optional and manual. You literally need to press a button labelled "Download favicon" before it connects to the internet.
I don't think the Debian maintainer is aware that the favicon download feature is optional and manual. You literally need to press a button labelled "Download favicon" before it connects to the internet.
Good discussion here: https://github.com/keepassxreboot/keepassxc/issues/10725
I have already been using bubblewrap[1] to isolate KeePassXC from the network and more (the only access it has is to its own private directory and a hardened Wayland socket[2]). I wouldn't recommend relying on devs or maintainers to do application isolation work for you.
[1] <https://github.com/containers/bubblewrap>
[2] <https://git.sr.ht/~whynothugo/way-secure>
[1] <https://github.com/containers/bubblewrap>
[2] <https://git.sr.ht/~whynothugo/way-secure>
This maintainer does not respect upstream developers. He must step down and pass this package to someone who respects the upstream developers and their judgement. He must not keeping this name hostage and damaging the brand.
I have a lot of respect for the Debian project but every now and then one of their maintainers does something completely stupid and unreasonable and expects applause
It's crazy the amount of power maintainers hold over someone else's software. This reminds me of the time when Fedora maintainers disabled GLES1 support in Mesa because "nobody should be using it anymore (there are newer OpenGL versions)", disregarding the fact that GLES1 was well and fully maintained upstream, and was and is still the only option on many devices.
>power maintainers hold over someone else's software
There's some subtle assumptions about ownership in this comment that aren't accurate, insofar as free and open source software is concerned.
FOSS software is not "someone else's" software. They may own the trade mark, but by releasing the software under a FOSS licence, they lose the right to control the direction the software may take. I'm free to copy it, edit it, and redistribute it as I see fit. So are you. So is Debian.
There's some subtle assumptions about ownership in this comment that aren't accurate, insofar as free and open source software is concerned.
FOSS software is not "someone else's" software. They may own the trade mark, but by releasing the software under a FOSS licence, they lose the right to control the direction the software may take. I'm free to copy it, edit it, and redistribute it as I see fit. So are you. So is Debian.
That's besides the point. You can do whatever with the software, but it gets muddy when you then release it under the same name as the original. That name may not be trademarked, but it is still not yours to use.
This simply is irrelevant. A FOSS licence fully permits what Debian has done here. So, that is beside the point.
[deleted]
Not even comparable.
Debian users can choose between the stripped and full version of Keepassxc, unlike the MESA example above.
> It is our responsibility to our users to provide them the most secure option possible as the default. All of these features are superfluous and do not really belong in a local password database manager
While that sounds like a reasonable argument, I think it misses the fact that you need reasonable usability to get users to use your product. E.g there's no way my wife will use KP of she doesn't have autofill, and she'd then revert to someone else's computer like lastpazs or 1password instead, which I'd argue is a worse solution in all ways possible.
The other thing that makes me question this a little, is removing yubikey support and auto type. While you don't get the full advantage of MFA, having a rotating encryption key is still an additional layer of protection. Meanwhile, without auto type you will need to copy-paste usernames and passwords - and listening to the clipboard is much easier than building a key logger.
I mean, if really what you're looking for is barebones, you can also not use a password manager and come up with a cypher instead.
While that sounds like a reasonable argument, I think it misses the fact that you need reasonable usability to get users to use your product. E.g there's no way my wife will use KP of she doesn't have autofill, and she'd then revert to someone else's computer like lastpazs or 1password instead, which I'd argue is a worse solution in all ways possible.
The other thing that makes me question this a little, is removing yubikey support and auto type. While you don't get the full advantage of MFA, having a rotating encryption key is still an additional layer of protection. Meanwhile, without auto type you will need to copy-paste usernames and passwords - and listening to the clipboard is much easier than building a key logger.
I mean, if really what you're looking for is barebones, you can also not use a password manager and come up with a cypher instead.
Should bave left the original KeyPassXC Debian package alone and ...
Instead to create a `keypassxc-offline` package with those tweaks.
Instead to create a `keypassxc-offline` package with those tweaks.
This should have been handled the same way Mozilla handles Firefox. KeepAssXC developers, file for trademark protection and then send a cease and desist to Debian legal.
If they want to misrepresent your application to Debian users, they'll have to do it under a different name or not at all.
If they want to misrepresent your application to Debian users, they'll have to do it under a different name or not at all.
I see in this an attitude that's become increasingly common since the 2010s among developers as well as software companies regardless of open source or proprietary - "We know what's good for you, the end user and we will decide on your behalf." and use this as an excuse to strip out features that had been long available. Firefox is a classic example.
In stark contrast to the previous norm of highly customizable software that catered to both newbies and power users. Right here we see the example of the maintainer unilaterally deciding to strip out a feature that's already been disabled, just because he decided he knows better what KeepassXC users ought to do.
In stark contrast to the previous norm of highly customizable software that catered to both newbies and power users. Right here we see the example of the maintainer unilaterally deciding to strip out a feature that's already been disabled, just because he decided he knows better what KeepassXC users ought to do.
That's a very misleading comparison. When Mozilla (upstream) axes a feature, it's gone permanently and you can't get it back.
Which is not the case here at all, here downstream turns off a feature in the default build, while simultaneously providing the fully featured version in a just as easily installable package.
Which is not the case here at all, here downstream turns off a feature in the default build, while simultaneously providing the fully featured version in a just as easily installable package.
We used to deploy on Debian at my previous place, and we hit this sort of shit all the time. Maintainer ripped out features they disagreed with (political reasons, or just engineering/product taste), maintainers changing the configuration files to things that suited them better, etc.
I understand it's all volunteer work, I understand it's open source so anyone can add their own custom packaging, on top, but Debian (the OS) certainly uses the ecosystem as a selling point, and it really can come back to bite you.
I understand it's all volunteer work, I understand it's open source so anyone can add their own custom packaging, on top, but Debian (the OS) certainly uses the ecosystem as a selling point, and it really can come back to bite you.
Could you provide an example where maintainer "ripped out" a feature because of a strictly political reason?
When I say "political" I'm referring more to belief systems, but calling them religious beliefs would be far too antagonistic for the point I'm trying to make.
Iceweasel is full of examples of parts of Firefox removed because the maintainers had personal disagreements on the values of Firefox. Firefox is a fairly privacy-forward browser and Mozilla stand up for a lot of those ideals, and yet Iceweasel pulls features and telemetry on the basis of them being by-definition bad. I think that's a politics/identity statement more than a UX improvement.
I strongly disagree with packagers putting their opinion on top of the software they are packaging, I think packaging should be as pure a translation as is possible for the target system. Now in the case of Iceweasel it could change the branding which I think would give them more leeway to put opinion into it as it's "not Firefox" and there's little risk of users being confused, but I'd also bet that Debian wouldn't accept another pure Firefox packaging because it would duplicate the package in their minds. If that is the case I think that nullifies the idea.
Iceweasel is full of examples of parts of Firefox removed because the maintainers had personal disagreements on the values of Firefox. Firefox is a fairly privacy-forward browser and Mozilla stand up for a lot of those ideals, and yet Iceweasel pulls features and telemetry on the basis of them being by-definition bad. I think that's a politics/identity statement more than a UX improvement.
I strongly disagree with packagers putting their opinion on top of the software they are packaging, I think packaging should be as pure a translation as is possible for the target system. Now in the case of Iceweasel it could change the branding which I think would give them more leeway to put opinion into it as it's "not Firefox" and there's little risk of users being confused, but I'd also bet that Debian wouldn't accept another pure Firefox packaging because it would duplicate the package in their minds. If that is the case I think that nullifies the idea.
A password manager without browser integration is essentially dead in the water. Seems like what they're shipping is unusable for most people. We all know 'unusable FOSS' cliché but in this case it actually applies.
These kind of "feature changes" in Debian packages is one reason I stay away from Debian.
And it's not just features that might change. A Debian maintainer introduced a bug in the OpenSSL random number generator making it insecure, a couple of years ago.
And it's not just features that might change. A Debian maintainer introduced a bug in the OpenSSL random number generator making it insecure, a couple of years ago.
> a couple of years ago
You’re bearing a grudge based on an unintentional bug introduced 18 years ago. Weak take and irrelevant to topic at hand.
You’re bearing a grudge based on an unintentional bug introduced 18 years ago. Weak take and irrelevant to topic at hand.
I think it's correct for the default package to be the safest-possible one. It's a password manager not an mp3 player.
Yes it's annoying that an existing behavior will change, but that problem is not more impportant than the problem of what should be the default behavior of a security app.
keepassxc should have always been like that by default and all the added conveniences that also add bug-surface and attack-surface should have always been things you have to go out of your way to add.
It wasn't and so now to fix that error requires a disrupting change, but that is not enough excuse for not fixing the error.
Yes it's annoying that an existing behavior will change, but that problem is not more impportant than the problem of what should be the default behavior of a security app.
keepassxc should have always been like that by default and all the added conveniences that also add bug-surface and attack-surface should have always been things you have to go out of your way to add.
It wasn't and so now to fix that error requires a disrupting change, but that is not enough excuse for not fixing the error.
Safest by what metric? Calling the browser integration a "convenience" feature only is just fundamentally wrong.
Realistically the most common attack most users face is a phishing attack, removing the browser integration which checks the URL programmatically before filling the password opens the user up to being phished more easily (users check URLs less consistently and less reliably), so arguably this makes the package less secure in the real world.
Realistically the most common attack most users face is a phishing attack, removing the browser integration which checks the URL programmatically before filling the password opens the user up to being phished more easily (users check URLs less consistently and less reliably), so arguably this makes the package less secure in the real world.
Debian is somewhat inconsistent with this but it does have precedent for package to be package-minimal and a corresponding full- variant.
Odd to just break users by doing this, should have been done with a major release when people expect breakage.
Odd to just break users by doing this, should have been done with a major release when people expect breakage.
Uh, it's only changed in unstable, so it will be a major release when current testing is released.
A password manager with a built-in MP3 player? That's my next project.
The songs could tell you where to find the post-it note within your record library. Let the hackers gain access to your google drive AND decrypt the db. :)
I abandoned KeePassX (pre XC fork) when they made wonky changes ~10 years ago.
Use Bitwarden (optionally run your own sync server) or Keeper (for less technical people).
Use Bitwarden (optionally run your own sync server) or Keeper (for less technical people).
I recently switched from BW to XC in the wake of their acquisition, and I have to admit, the mobile experience is just a little more annoying. But I sleep better at night knowing that I don't keep anything critical on servers I don't own.
1. What acquisition? https://bitwarden.com/blog/
2. You can run your own FOSS Bitwarden sync server. It even works airgapped.
https://bitwarden.com/help/install-and-deploy-offline/
2. You can run your own FOSS Bitwarden sync server. It even works airgapped.
https://bitwarden.com/help/install-and-deploy-offline/
What is the big issue? The maintainer put up two packages, one stripped down and another with full functionality.
I'd say it's really good to have options so the user can choose themselves.
I'd say it's really good to have options so the user can choose themselves.
They made the default the stripped-down one, which removes security features like the anti-phishing prevention in the browser extension.
So in the end they reduced the attack surface for a program running on your computer by increasing the attack surface on the meatbag operating the computer? (i.e. browser integration which is the only effective thing against phishing)
Seems like a good deal /s
Seems like a good deal /s
This reminds me of the how to secure a trashcan from bears in yellow stone: the dumbest person and the smartest bear has significant overlap.
Protecting a few dumb people means exposing a lot more people to attack vectors.
Protecting a few dumb people means exposing a lot more people to attack vectors.
Fortunately Debian maintainers have a fantastic track record of writing ad-hoc patches for security-sensitive software.
rurban(4)
People always crap over LastPass, but when you ask them what they do, it’s some elaborate process relying on thousands of no name packages and devs.
The maintainer's position seems reasonable to me. A different package, compiled with the network features, is provided too. I like this as a default.
It sounds like a necessary but painful change if we want secure by default.
I like this solution. He reduced the attack vectors in the base application by removing features a large majority of people don't use. And if they want these additional features then download the full version.
> features a large majority of people don't use.
I would be shocked if this was true. I have recommended KeepassXC to many of my friends and family and they all use at least one of the features that was in the removed list. To be fair, none of them use debian, but some of them do use other Linux distros.
I don't use debian on desktop anymore on my main machine, but I did use BunsenLabs for a long time and even back then KeepassX (and afterwards KeepassXC) auto-type was a critical feature I used literally every day.
I would be shocked if this was true. I have recommended KeepassXC to many of my friends and family and they all use at least one of the features that was in the removed list. To be fair, none of them use debian, but some of them do use other Linux distros.
I don't use debian on desktop anymore on my main machine, but I did use BunsenLabs for a long time and even back then KeepassX (and afterwards KeepassXC) auto-type was a critical feature I used literally every day.
I never knew KeepPassXC could talk with my browser or interact with ssh until I saw this thread, and I've been using it for almost 10 years now.
Seems like a positive change to me.
They disabled all plugins, not just those that may access networks.
This is not good, it's nonsensical.
This is not good, it's nonsensical.
Thinking browser or other local integration is not as dangerous as network features is nonsensical.
All of the disabled features are expendable. I never used any even while they were in there. Yet I do use keepassxc all day every day for the one job it actually does exist to do.
Convenience and necessity are two different things. You want conveninece, and you're not wrong to want it, but you don't need it, and your want of convenience is not important enough to make the base utility when it is a password manager and not a gif editor less safe than it could be by default. It is correct that if you want to trade away safety for convenience, that you have to go out of your way to add that yourself, even if most people will choose to do that, and even if the previous default was backwards and it's now ever so slightly disruptive to correct that error now.
All of the disabled features are expendable. I never used any even while they were in there. Yet I do use keepassxc all day every day for the one job it actually does exist to do.
Convenience and necessity are two different things. You want conveninece, and you're not wrong to want it, but you don't need it, and your want of convenience is not important enough to make the base utility when it is a password manager and not a gif editor less safe than it could be by default. It is correct that if you want to trade away safety for convenience, that you have to go out of your way to add that yourself, even if most people will choose to do that, and even if the previous default was backwards and it's now ever so slightly disruptive to correct that error now.
Browser integration, if done well, is actually more secure than the copy+pasting you end up doing otherwise. Storing passwords in the clipboard is a massive security risk, as the clipboard is shared by all applications and websites, while direct browser integrations allow for only providing the credentials to the specific web page they're meant for.
While I'm not opposed to differentiating between a -full and a -minimal version, calling every plugin dangerous by default doesn't make sense.
While I'm not opposed to differentiating between a -full and a -minimal version, calling every plugin dangerous by default doesn't make sense.
>if done well
Is that xkcd of a tiny project doing a lot of heavy lifting.
Is that xkcd of a tiny project doing a lot of heavy lifting.
Removing browser integration and auto-type doesn't increase security, it reduces it by exposing users to clipboard sniffing attacks and phishing websites.
Absolute security means you can't do anything. Too much security friction can easily lead to *much more insecure* workarounds.
Somehow, I have been using the same app without any of those features. So, the idea that the app is not functional or useful without them is bullshit.
As for friction leading indirectly to less security through user behavior... how many clicks and how many seconds is it to install the full version? So, yet more bullshit.
As for friction leading indirectly to less security through user behavior... how many clicks and how many seconds is it to install the full version? So, yet more bullshit.
> Somehow, I have been using the same app without any of those features.
And are you putting your passwords on the clipboard in a way that doesn't verify domain names?
Congratulations, you're using insecure methods. Not bullshit.
And are you putting your passwords on the clipboard in a way that doesn't verify domain names?
Congratulations, you're using insecure methods. Not bullshit.
> Convenience and necessity are two different things. You want conveninece, and you're not wrong to want it, but you don't need it, and your want...
> Somehow, I have been using the same app without any of those features. So, the idea that the app is not functional or useful without them is bullshit.
Different people might have different needs and wants and other criteria to consider it functional? I think this is not up for you to decide.
> Somehow, I have been using the same app without any of those features. So, the idea that the app is not functional or useful without them is bullshit.
Different people might have different needs and wants and other criteria to consider it functional? I think this is not up for you to decide.
Hissy-fits like these are one of the reasons there's never going to be a "year of the linux on desktop"
But why do they care, right? Most people on their irc channel (that have a basement NAS may I add) agree with their decision.
Now my bet is that your average Debian user does care about convenience. Replacing (default off) selection boxes with different sw packages is acceptable in only a minority of cases, and doesn't seem to be the case here.
But why do they care, right? Most people on their irc channel (that have a basement NAS may I add) agree with their decision.
Now my bet is that your average Debian user does care about convenience. Replacing (default off) selection boxes with different sw packages is acceptable in only a minority of cases, and doesn't seem to be the case here.
There was some comment about it. Basically, it's for security reasons. Those who aren't using those features wouldn't expect them to appear (especially sneakily). And those who are planning to use them will figure out what package to install.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529
This was the message from maintainers:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529
This was the message from maintainers:
Networking and all plugins have been moved into
the keepassxc-full package.
Feature creep like SSH agent support, browser
integration, Freedesktop.org secret storage,
KeeShare pose undue risks for most users.Browser integration and autotype are not feature creep.
Making everything copy-paste is bad for security.
Making everything copy-paste is bad for security.
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.