Gutting the functionality that upstream has built into a piece of software and then publishing it under the same name is dubious at best. If they want to go this direction they should publish as a fork under a different name so upstream doesn't get constantly barraged by complaints of users having issues.
This reminds me of the time years ago when the Debian maintainer of Chromium decided to unilaterally disable the ability to install extensions. Thankfully, more pragmatic minded people prevailed and the patch was reverted.
This also reminds me of a time many many many years ago when Debian removed the kernel interface that provided the ability to load binary firmware into network cards and broke networking for me.
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.
> 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.
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"
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.
> 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"
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.
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.
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.
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.
This reminds me of "The gift of it's your problem now" (2021):
The best part of free software is it sometimes produces stuff you never would have been willing to pay to develop (Linux), and sometimes at quality levels too high to be rational for the market to provide (sqlite).
The worst part of free software is you get what you get, and the developers don't have to listen to you. (And as a developer, the gift recipients aren't always so grateful either.)
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 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.
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.
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.
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.
- 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.
> 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.
> 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).
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".
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.
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.
> 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.
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.
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.
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”?
> 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.
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.
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.
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.
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.
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!
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.
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.
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.
"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.
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.
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.
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.
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.
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.
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:
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.
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?
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.
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?
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.
It is marked as 'Priority: standard' thus installed as part of the standard Debian installation and shows only NEWS entries by default without needing further configuration.
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.
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 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.
-DWITH_XC_ALL=[ON|OFF] Enable/Disable compiling all plugins above (default: OFF)
To me, it seems like the maintainer is simply bringing the default package back to what it should have been, and he's offering another build with all features enabled under keepassxc-full
If KeepassXC is unhappy with the defaults, they can adjust theirs to reflect what they feel should be available out of the box.
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.
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.
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.
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.
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".
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.
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.
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?
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.
>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]
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.
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.
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.
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.
> 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.
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.
> 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?
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'
> 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...
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
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.
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 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?
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
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.