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.

>> 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"

This build option exists. If you're building from source and don't need any of the extra features, you can use it to get a leaner binary. But the Debian maintainer made this decision for everybody, removing important security features (such as browser integration and YubiKey support) from the main `keepassxc` package, which broke people's existing installations, and which means that people blindly running `sudo apt install keepassxc` will get an inferior, less secure product.

[0] https://github.com/keepassxreboot/keepassxc/blob/develop/INS...

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.

In this case, there does seem to be reasonable security justifications for it, and an alternative is provided.

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.

[0] https://keepassxc.org/donate/

   The best part of free software is it sometimes produces stuff you never would have been willing to pay to develop (Linux), and sometimes at quality levels too high to be rational for the market to provide (sqlite).

   The worst part of free software is you get what you get, and the developers don't have to listen to you. (And as a developer, the gift recipients aren't always so grateful either.)

https://news.ycombinator.com/item?id=29736369

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.

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

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.

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

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).

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.

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.

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.

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.

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.

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.

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

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

That's what some users seem to want today. It's why both Flatpak and Snap exist with the goals of letting upstream developers just CI/CD spit out a "universal" package for Linux and getting a more "Mac-like" (or "Windows-like" if you prefer) install experience with less waiting for package maintainers to get around to publishing upstream changes.

Admittedly, Flatpak and Snap aren't universally beloved either, yet, but the balance of what the job for a distro's package maintainers should be is definitely in shift.

That said it probably makes more sense for Debian to package a `keepassxc-nonet` alongside the default `keepassxc` so end users can choose the variant.

Wahey, isn't that what MS does with e.g. Outlook. Congrats Debian, you're reaching Microsoft's level!

"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.

In this case it’s features that were patched out - not plugins or a mere config change.

The Debian package wasn't shipping the correct default configuration in the first place, it's unfortunate but better late than never, and it's not like you can't switch to the keepassxc-full package.

The devs said they're not actually plugins, and that was quoted here hours before you commented.

https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

> This is now our fourth bug report because of the decision to neuter the base KeePassXC package in Debian

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.

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?

I'm one of those users. If I'm loud, does that mean my opinion doesn't count anymore?

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/

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 :-<

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.

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.

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.

By their making the decision they think is best and that agrees with the philosophy of the distribution they're maintaining the package for? I'm glad they don't have to justify their existences to upstream and every "significant portion[...] of users."

> It's KeePassXC's job to secure the software and produce features that fulfill users' needs as they see fit.

You don't control free software after you've licensed and distributed it that way. The entire point of the concept is to make calls like this about anti-features. KeePassXC can feel free to comment on it, like anyone else. They can demand that Debian make available the modified sources. They can revoke any license to the use of trademarks. That's it.

If users only want to deal with KeePassXC, they can compile it themselves or use a portable version. If KeePassXC wants to deal with Debian users directly, they can host a package repository for their canonical version.

By the same argument we should remove encryption as well, because it increases the amount of code and thus the attack surface.

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?

I would be pissed if a FreeBSD package was some non-standard configuration.

> I would be pissed if a FreeBSD package was some non-standard configuration.

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".

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.

I maintain two upstream projects where Debian unilaterally decided to rename the package. In one case I found out much later, in the other case it was against my express objection and was completely nonsensical.

Of course I’m the one who has to explain it to users.

Edit: see the arrogance of the Debian guy (Julian) here: https://github.com/keepassxreboot/keepassxc/issues/10725#iss... - that’s what I’m talking about.

EDIT: link to a KeeppassXC maintainer explaining that they're not plugins: https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

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.

They'll have to type apt install keepassxc-full ENTER after reading about the packaging change which they've been shown during package update.

Wow what a nuisance.

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.

In this case, though, it's not even a patch - it's a build flag that is provided by upstream.

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.

Oh, the horror of being in unstable/testing channel and ignoring the change notice which has been shown automatically during apt-get upgrade.

Deferring to “it’s in the notes!” means nothing if you have more than a handful of packages on your machine.

You should also clarify the assertion that packaging affecting testing target won’t eventually hit stable, because that would be a major change that I haven’t heard about.

An end user will get impacted by this eventually.

What are you talking about? This is an upstream build option. Has upstream forked itself by providing this option?

in this case it seems like the debian maintainer moved optional functionality that was opening security holes to the keepassxc-full package, and the keepassxc maintainers are lying about it by saying that he has 'decided to remove ALL features from it'

in https://github.com/keepassxreboot/keepassxc/issues/10725 the debian maintainer explains:

> It is our responsibility to our users to provide them the most secure option possible as the default. All of these features are superfluous and do not really belong in a local password database manager, these developments are all utterly misguided.

> Users who need this crap can install the crappy version but obviously this increases the risk of drive-by contributor attacks.

and yeah i really, really do not want my password manager to by default communicate with random web pages. that should be opt-in functionality and always should have been. given that it wasn't, there's no good option, but this is the least bad one

one of the great benefits of free software is that it makes it hard for misguided or malicious maintainers to push antifeatures on users, because the users can always use somebody else's version of the software, for example, debian's or f-droid's. trusting debian to prevent shenanigans like the keepassxc team's is my biggest reason for using debian instead of something else

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

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

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.

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.

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?

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

Remember, the full network-enabled package is present in debian as well - so all the network features are "apt install keepassxc-full" away, for users that want it.

Two minor comments: calling your upstream "crappy"[0] is probably not the most productive way for package maintainer to act. Also, I am not sure if the package names (keepassxc vs keepassxc-full) are best for Debian users - something like keepassxc-lite and keepassxc-full might be more informative.

[0] https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

[1] https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

And "being useful" can increase security because if password managers are hard to use then people stop using them.

And looking at this a bit more, it's not clear to me that using the clipboard is necessarily more secure than the browser integration. Copy/paste accidents alone would offset quite a bit of the security footprint of a browser integration.

Many years ago I did some contracting for a fairly large company.[1] The laptops of their account managers had a disk encryption passwords, Windows login password, and AD login password. They all had to be different. They all had to be changed every few months. They all had "must contain at least two capitals, at least 4 non-letter/digits, and at least one 11 digit prime number"-type requirements.

Every single laptop I ever saw had a post-it note with all three passwords. Without exception.

My point here is: hypothetical security nerd security does not equal actual real-world security. Or at least not always. There are real trade-offs to be made here.

[1]: We did some maintenance of the laptops as an external contractor for some of the guys. They weren't really supposed to, but it was tons faster and easier because less bureaucracy, as doing it by their own IT system took forever. It was that type of company. This, on its own, was of course also a "security risk" because random tech guys from a computer store shouldn't really be on their laptops with super-secret company data (I don't think there wasn't that much to protect, other than sales/customer numbers which is only useful for a very select group of people).

Oh and I'm not only talking about elderly relatives and such. Modern phishings are very very well made, and there's one going on to steal Steam accounts that I would have likely fell for (and I consider myself pretty good on the matter).

Often I'm just browsing along and try to get KeepassXC to autofill a password only to be frustrated when it refuses to work. Then the frustration turns to relief when I go into KeepassXC and see that I've entered "https://website.com" into KeepassXC's URL box causing KeepassXC to only autofill the password on the HTTPS variant of the website and I was on the HTTP variant of the page.

Obviously it's best for the website to just setup HSTS, but I can't fix that for them.

I previously used auto-type and always thought browser extensions were insecure until I realized this.

Turning off the browser intergation means that the user may accidentally auto-type into the wrong website. Turning off auto-type means that external applications can see the password.

That said, this ends up also making this like clipboard managers or wl-paste not work, so there is a wlroots protocol (wlr_data_control) that lets the client know about all data offers. How is a malicious process prevented from being a client of this interface (or even should a process be prevented...) depends on the compositor.

As noted elsewhere, one of the "optional" flags that got disabled is yubikey support, without which users are getting locked out of their password manager when they upgrade to the new, broken package. Enabling just that flag puts the project in a state which nobody is actually testing.

I agree that calling the package keepassxc-lite would have prevented this issue, assuming existing users were moved to keepassxc-full, but that's the entire problem here! It's a reasonable choice to default to the most secure solution (not that hypothetical attack surface is a real vulnerability), but as a maintainer you shouldn't break existing functionality unless either upstream or your users want you to, and you particularly shouldn't lock users out of their password manager.

So they should be thankful their software will have better test coverage thanks to Debian users

This is so incredibly rude to post on the github it'd make me reconsider using Debian at all if I did. If the package is so full of "crappy" features why is he even bothering to maintain it? Just get rid of it and let users figure out how to install it properly themselves.

I feel bad for KeepassXC devs, maintaining an open source project is hard enough without having to deal with crap like this.

But then I gave up on debian a while ago because of some of their more questionable decisions.

There is a some confusion because the flags that control these features at compile-time do default to OFF if not provided, but the installation instructions in the same documentation also tell you to compile with XC_ALL set to ON. The maintainers themselves talk about all features being enabled at compile-time in the discussion thread and even consider removing these compile-time flags altogether to prevent compiling keepassxc without these features. So "disabled by default" is not really an accurate understanding. It is clear that the intended configuration from the authors is for all features to be compiled in and available.

See: https://github.com/keepassxreboot/keepassxc/issues/10725#iss... https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

Current users will have their install broken and need to google to figure out what is going on.

Future users will install `keepassxc` thinking it would be actually KeePassXC before potentially realizing its a minimal version.

Personally I think splitting it into `keepassxc-full` and `keepassc-minimal` would be better since it moves the choice to the user instead of implying the contents.

apt shows the NEWS file during update when there's a change. If it doesn't (ie. user set it up to blindly do the upgrade), you can still check the news file or .debian.changelog.gz file afterwards.

And note that this happened in testing/sid channel, where breakage is supposed to be happen. When this change shipped in the new major Debian stable release in a few years, it'll surely be clearly written in the release notes.

What else do you expect, SMS notification? :P

If a user haven't seen the above he for sure won't see an announcement in a crowded debian-whatever-announce mailing list he isn't subscribed to or an obscure blog post posted somewhere he doesn't follow.

If it doesn't (ie. you set it up to blindly do the upgrade), you can still check the news file or .debian.changelog.gz file afterwards.

Lastly, when it's shipped in the new major Debian stable release in a few years, it'll surely be noted in the release notes.

I would go crazy w/o autotype. The way the IT dorks were forced by management to set up 'SSO' via an external provider at work, you have to enter the same information at least 3 times a day. 'SSO' for management means 'sign into each of our tools each single day'. Muh, no work done equals better security!

By that, I mean three different Okta logins, and logging in to any of them will log you out of the other two. If I want to do anything, it means I need to log in again because it is unlikely that I am logged in to the right account.

Yes, I need all 3 multiple times daily. There is no logic about which one I need for which system.

IT knows this is not how it is supposed to be, but they assure us that this is a temporary situation. I guess 1.5 Years is still temporary.

Also you can create a separate browser profile for each account. This works with all browsers but is less convenient, because it forces you to have a separate browser window for each profile, and also you need to enter all preferences for each profile separately.

Guess who keeps their password saved in notepad, all but three characters?

It's horseshit, but it's an argument

lets see what it does here...

NikkiA

edit: well, I guess it didn't broadcast the password, but it probably would have done on a real chat window that accepted multiple lines of input

Because in the real world, with real users, you must balance security and friction. If you have too much friction, users look for workarounds and your theoretical security increase becomes a real world security decrease.

For a real world example of this phenomenon, see forced arbitrary password changes (which are now universally discouraged). They are theoretically more secure, but study after study has proven that, in the real world, forced arbitrary password changes reduce organization-wide security.

Security requires a holistic approach. Users and their behaviors are part of that. Looking only at attack surface is a sure-fire way to make your users work against your security policies rather than with.

> You fundamentally misunderstand our program when you use the word plugin. These are built in features, not plugins. The features can be enabled as desired by the user and they come disabled by default. This change to not compile and ship these features in the base keepassxc package does nothing besides create angry (or confused) users.

Because if it removes features many (perhaps even most) people use then that makes it less useful. And potentially insecure as people will stop using KeePassXC and replace it with "passw0rd123", because "I really need to get this done now, and not fuck about with KeePassXC not working". Is there even a message? Or any indication in the UI what's going on? I don't think there is.

Here's what should have happened if you really think that "keepassxc" package should install a minimal version: contact maintainers of KeePassXC, discuss best way to do this, maybe allow them some time to create better UX on this. Maybe create a PR or two. And then change your package. That Debian bug was 4 years old – it could have waited a month or two more.

You're also far too hung up on the word "plugin". That word has tons of meanings, and the original meaning of "something optional I can add (plug in) later on" doesn't really apply here.

What's stopping a malicious actor from including malicious network code outside of the compile flags?

Disabling compile flags on functionality doesn't necessarily guarantee you're any more secure, especially if the software isn't regularly tested without those flags.

If the software (1) only ever used on trusted data (2) never makes network requests, then even with most vulnerable libraries, it simply cannot be exploited. But features like "fetch favicon from untrusted websites" open huge security holes in case there are ever bugs in http or image libraries.

(note that in case of local compromise, it does not matter if keepass is secure or not - the attacker can install keylogger, inject code into process or replace it altogether)

You're assuming the flags remove all of the whats-deemed-as-risky behavior.

Trusting the flags from the lens of wanting to trim down a package size? Reasonable.

Trusting the flags from the lens of wanting to boost security? Eh... Crafting a security policy based on compile flags requires a lot of trust towards the developer of the code or spending a lot of time auditing these compile flags.

I just don't see the logic in wanting to simultaneously avoid trusting the code while also placing an enormous amount of new trust in the code's post-compile behavior.

> But features like "fetch favicon from untrusted websites" open huge security holes in case there are ever bugs in http or image libraries.

Image support is still built in, though. You're still susceptible to the vulnerable image library. Just because you're now pulling the images by hand doesn't make it any more secure.

With these concerns users should be considering some form of sandboxing. Whether it's tossing the package in a network-restricted container, VM, or separate device. This is very close to dogmatic security theater.

I am worried about unintentional bugs which end up being remotely exploitable.

So while making sure the image library is bug-free is practically impossible, it is pretty easy to check for compile-time feature flags. Build it once, then ldd to make sure the http library is not linked. Or check debug messages. Or objdump and make sure method is missing. Tons of very simple methods.

From this standpoint, disabling favicon fetching is a 100% effective mitigation for all remote attacks. I've never bothered uploading favicons by hand, and I've never needed any images in my notes.

No security theater, just a pragmatic view.

CMakefiles are susceptible to bugs too. KeepassXC could also very well remove these build flags and people would be none the wiser.

As I said, concerned users should look at other ways to isolate the application’s behavior here instead of relying on the build process.

Run it in an isolated network namespace if network connectivity is the prevailing concern.

The keepassxc account is being ridiculously sensationalist. Removing ALL features? Lol

> I think the proper solution would probably be to package both a "-full" and "-minimal" version of the software and utilize Debian package meta-data fields to define a Conflicts relationship between the packages and tag them also both with a Provides for keepassxc and also add a tag Replaces: keepassxc to the -full build so that during a package upgrade an existing user would be provided the version that continues to provide the features of the package which is being upgraded/replaced while new users can choose for themselves which of the versions they'd like to install

https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

Why would this _not_ be the obvious choice?

If an engineer of mine pulled this on our user-base I'd have them reverting it in a heartbeat regardless of the technical merit. They already failed just in how they executed this and have burned good will, the technical merits no longer matter. Once you've lost the faith and trust of the user, it's over.

The original request[0] was more or less simply a user asking for the networking to be removed, and follow-up to just have a -nonetwork variation. Instead, we have comments from the debian maintainer:

The OP report: > Users who need this crap can install the crappy version but obviously this increases the risk of drive-by contributor attacks.

The debian package description[1]: > See keepassxc-full if you absolutely need those.

The PR[2] > Feature creep like SSH agent support, browser integration, Freedesktop.org secret storage, KeeShare pose undue risks for most users.

Each one of these sends a message. And it was entirely avoidable with a bit of grace and kindness to the existing userbase.

[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529

[1]: https://packages.debian.org/sid/keepassxc

[2]: https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f...

The software has been broken - the UI wasn’t designed with those toggles in mind so now users suddenly have non functioning features presented to the in the UI.

The argument the all users should be keeping up to speed on NEWS - especially in the stable channels this will end up in - to explain why their UX is suddenly broken is not exactly ‘user friendly’.

They don't need to, it is shown to them during apt-get upgrade

> especially in the stable channels

This is in testing/unstable. Stable users aren't and won't be affected until until the next major Debian version is released and the users decides to do the upgrade.

With IoT everyone have access to your LAN, so now people are making sure linux also join the REDACTED party

btw, fix for fwupmdg, since they have a low quality default conf file without commented out defaults:

   ```
   # /etc/fwupd/fwupd.conf
   [fwupd]
   P2pPolicy=none
   ```

   ```
   # /etc/systemd/resolved.conf
   [Resolve]
   DNS=9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net
   FallbackDNS=127.0.0.1 ::1
   Domains=~.
   DNSOverTLS=yes
   LLMNR=no
   DNSStubListener=no
   ```

veering offtopic: I always thought mDNS was an Apple thing, since Bonjour is the most extensive implementation of it (and Windows sucks at it. In fact the only way I found to get a full mDNS implementation on Windows a few years ago was to install Bonjour via an installer extracted from iTunes for Windows).

The Wikipedia page for mDNS [1] doesn't have a lot of history information, saying just that the idea of mDNS was first proposed by Bill Woodcock & Bill Manning to the IETF in 2000, and neither seem obviously tied to Microsoft. Apple later published Bonjour in 2002, and mDNS only became an official rfc6762 in 2013!

[1] https://en.wikipedia.org/wiki/Multicast_DNS

it goes like this:

1. MS uses netBios.

2. apple uses bounjour, similar to netbios, but with modern conveniences, like NAT aware.

3. windows add same niceties on top of netbios and call it LLMNR.

4. apple standardize bounjour as mDNS and open it up just because they would have to publish code because of some licenses they offended (but going into this is veering way too much offtopic on your offtopic)

5. everyone standardize on mDNS

6. RedHat (using their fake open source promotion called freedesktop, nee XDG) pushes for LLMNR for god knows why! (well, might be a reason poetering works for MS now)

7. even microsoft abandon LLMNR and netbios in favour of mDNS. everyone is using mDNS. RH/freedesktop/systemd/fwmg (all the same people) chose to base their LAN distribution service logic on LLMNR.

8. RedHat works backward compatibility of LLMNR into mDNS and things get VERY confusing. Or not. Their documentation uses the name interchangeably and honestly, at this point I am not sure of anything and I'm not paid to look at that code for over a year. I wouldn't be surprised if resolved is actually using mDNS but the setting/code is still just "called" LLMNR. /shrug.

Our goal is to create an application that can be used by anyone while still offering advanced features to those that need them.

It is ultimately their decision to make, but that doesn't mean it is a good one, I contend it is not.

> In the lead up to this thread I received three reports of this new package method crippling people's workflow. One report was a user who couldn't open their database anymore because the yubikey feature was removed. Let that sink in for a second. People who lose access to their most important secrets can sometimes do irrational things in the moment of panic.

https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

This sounds like emotional blackmail

How many times I lost everything, hardware failure, updates that broke OS, using dd in the wrong drive...

This is more secure than using a simple password or (gasp) an unencrypted copy somewhere.

If Debian shipped a Linux kernel point release that disabled networking I think people would be similarly upset, even though it's also just a build option and intended to be a valid build configuration (and would even more secure!)

That is not comparable. "If Debian shipped a Linux kernel point release that removed a risky networking plugin and some disabled-by-default plugins and made a -full version" that would be comparable.

BS. This change was in Debian sid/testing. That's what it's for. Debian stable users' workflow hasn't been broken.

I appreciate that it often doesn't happen, but that's supposed to be the default flow regardless: If you're using a distro-provided package and hit a bug, you're supposed to open a bug report against the distro package, and then the maintainer looks at it, and if the bug came from upstream then they file a bug with the upstream project. This is helpful because 1. the package maintainer is probably familiar with the package and can provide initial triage/analysis, possibly even being able to fix the bug outright before going upstream to share the fix, and 2. as you note, distro packages frequently carry some amount of patching and the maintainer should verify whether the bug is in their packaging or the upstream source code.

Unfortunately, many users default to reporting upstream first:( So in practice this is a concern, but it's really not supposed to be.

A downstream maintainer making small changes to fit within the OS that doesn't meaningfully affect the app is fine. A downstream maintainer modifying an app and removing core functionality so the upstream dev gets a ton of grief is not.

the maintainer has enabled all plugins (including network stuff) in the keepassxc-full package, the keepassxc package will be just the basics with a much better security posture.

that's obviously completely fine and completely within the remit of a maintainer, the entire complaint is about this being a change.

So you shouldn't have "keepassxc" and "keepassxc-full". Instead you should have "keepassxc" and "keepassxc-minimal".

But in this case, upstream has responded and clearly indicated that they do not want the minimal distribution of KeepassXC to be branded as the main "keepassxc" package: https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

They altered the config flags in a way that doesn't have the intent of the upstream project. And I would classify build config changes as a subset of "changing a package".

I'm pretty sure some compromise could theoretically be reached here. But not with that attitude. "It is our responsibility to our users to provide them the most secure option possible as the default"? You know what would be even more secure? To disable all networking in any program, and in fact, in Linux itself. Actually, it's even more secure to just not give people a computer at all. This is one of those stupid discussion-stoppers.

These kind of Highly Opinionated Maintainers™ has always been what put me off from Debian (and by extension, Ubuntu). I want to use KeePassXC, not "KeePassXC as some random guy thinks it should have been".

plugin, compile time ./configure flag, whatever - package maintainers extremely routinely create multiple versions of a package for various reasons, from security (this case) to dependencies (Debian contains a emacs-nox package that is emacs compiled without X libraries to avoid dragging them in on servers, for example) to license reasons.

again, all of the complaints are literally about the change, which the maintainer has decided to do in a disruptive fashion.

> I'm afraid that's not going to happen. It was a mistake to ship with all plugins built by default. This will be painful for a year as users annoyingly do not read the NEWS files they should be reading but there's little that can be done about that.

> It is our responsibility to our users to provide them the most secure option possible as the default. All of these features are superfluous and do not really belong in a local password database manager, these developments are all utterly misguided.

> Users who need this crap can install the crappy version but obviously this increases the risk of drive-by contributor attacks.

I deal with enough packages in my life that do massively breaking changes in point releases though, to be honest. This is reminding me of the good days that `apt upgrade` would uninstall the X-Server because nvidia fucked up their stuff.

Debian is kinda one of the places I expected to be better, and usually it does. (EDIT - And I guess the fact that this is causing a ruckus in testing is an indication of that. lets see how it develops.)

Whether it happened in a point or major release of Keepassxc is irrelevant, because ignorant users who upgrade their sid/testing installations blindly as if it was stable-security would have hit it eventually.

There are multiple KeePass implementations. The people using this one are doing so because they want its features.