114 replies
1d1h
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.
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.
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
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.
He wasn’t randomly messing with it, there was a bug report about this:
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.
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.
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.
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.
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?
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”?
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
I think that expectation ends once you start calling the other party's software "crappy".
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.
And the software authors made it clear that those features, even if compiled in, are disabled by default and the code never executes.
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.
Package maintainer != Project maintainer.
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.
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.
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.
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
"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.
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...
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...
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.
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?
My .vimrc is 8 lines. I learned not take the kitchen sink with me on holiday.
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.
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.
What’s your point? We all know why it’s happening. The reality is that it’s not to user expectations, which is bad.
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.
Hyperbole!
$ apt install keepassx
$ apt install keepassx-full
Choice made.
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
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.
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?
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.
They were. apt shows the NEWS file during update when there's a change.
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://apenwarr.ca/log/20211229https://news.ycombinator.com/item?id=29736369
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."
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 default build of KeepassXC is without any optional modules
https://github.com/keepassxreboot/keepassxc/wiki/Building-Ke...
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-fullIf 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.
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.
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."
What is the physics of someone sniffing your passphrase with a keylogger?
The same as someone sniffing the Yubikey communications.
except yubikey communications are not static, so unlike password, sniffing it doesn't allow attacker to open all future versions of the db
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.
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).
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.
Disclaimer: I don't use Debian, so I don't have a horse in this race.
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".
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.
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.
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.
They can do that... under a name that doesn't mislead people. Is that so hard?
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:
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 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.
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
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.
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...
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.
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.
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.
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.
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'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.
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.
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...
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.
Oh no, xscreensaver or GNU Parallel flame war once again.
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.
Isn't this just FOSS working as intended?
There are lots of distributions other than Debian.