KeePassXC Debian maintainer has removed all network features
fosstodon.org
fosstodon.org
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.
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...
> none of these features are plugins. All of them are built-in functionality that belong to the main product. If anything, we will reduce the number of such compile-time flags in the future, so these things cannot be disabled anymore.
https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
>> none of these features are plugins.
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...
You're right, I missed it there. Silly me for assuming that all of the recommended CMake flags would be specified in the section titled "Recommended CMake Build Parameters"
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.
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.)
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.
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.
> 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.
I think that expectation ends once you start calling the other party's software "crappy".
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.
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.
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.
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.
"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 instance the maintainer of the Debian package for KeePassXC has unilaterally made a choice.
You also owe it to your users to not mislead them by claiming that your modified version is actually the real FooBar.
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.
And I, as an end user, am absolutely fine with that, as a user of vim-nox package etc etc...
I'm one of those users. If I'm loud, does that mean my opinion doesn't count anymore?
They were. apt shows the NEWS file during update when there's a change.
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.
$ apt install keepassx
$ apt install keepassx-full
Choice made.
https://github.com/keepassxreboot/keepassxc/wiki/Building-Ke...
-DWITH_XC_ALL=[ON|OFF] Enable/Disable compiling all plugins above (default: OFF)
If KeepassXC is unhappy with the defaults, they can adjust theirs to reflect what they feel should be available out of the box.
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.
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."
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?
They can do that... under a name that doesn't mislead people. Is that so hard?
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...
Hopefully this will get fixed
Like sure there is breakage, if you don't read the news before upgrading major versions.
This is false, or at the very least misleading. It doesn't take much to go on the repository and give a closer look instead of repeating "what other said". Kwpolska already wrote it in this thread, -DWITH_XC_ALL (the flag that's been turned OFF in the original Debian package rules) is explicitly called in the build instructions, and not only there but also one release tool [1] and snap config [2]. This is merely how the project manages its build configuration, with specific flags turned off and one master toggle enabled by default (or expected to be passed to cmake/bash release tool). Same thing for the ppa packaging. [3]
0. https://github.com/keepassxreboot/keepassxc/blob/develop/INS...
1. https://github.com/keepassxreboot/keepassxc/blob/da90319d2d0...
2. https://github.com/keepassxreboot/keepassxc/blob/da90319d2d0...
3. https://github.com/keepassxreboot/keepassxc-packaging/blob/9...
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.
Your words, not mine.
It isn't buried somewhere, it's in NEWS.Debian file, and it's shown to user during the package update by default.
[0] https://salsa.debian.org/debian/keepassxc/-/blob/main/debian...
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.
There are lots of distributions other than Debian.
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.
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...
These are all features that are turned off by default.
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!
Guess who keeps their password saved in notepad, all but three characters?
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.
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
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.
How anyone could see a smaller attack surface as a bad thing on HN baffles the mind. Could he have made a -minimal version? Sure, but the default version should be the clean, secure, without plugins version so he did the right thing.
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.
No one was really friends with tom on myspace.
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.
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...
This isn't user hostile.
You know what'd be user hostile? Removing the functionality and not providing the -full package alongside.
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.
The original post is just a badly written clickbait. Nothing was removed, it was just moved to the keepassxc-full package.
Users who already have the keypassxc package will need to explicitly switch packages if they want the full one. That's not the same behaviour as described in my quote comment.
If the "keepassxc" package is to be replaced by the two alternatives ("keepassxc-full" and "keepassxc-minimal"), you'd still need a transitional dummy package named "keepassxc". That package would depend on "keepassxc-full | keepassxc-minimal", giving the user a choice to satisfy the dependency by installing either of those. So far so good. What if the user doesn't explicitly choose, though? The idea is that an upgrade would keep the "-full" variant but "apt install keepassxc" would pull in the "-minimal" variant. How do you encode this in Debian package metadata?
I think both "apt install" and "apt full-upgrade" will simply choose the first alternative, so you get either "-full" in both scenarios, or "-minimal" in both.
Absolutely insane to me, and I would not be surprised if there's an xz type of exploit hidden somewhere in the chain.
[1]: https://github.com/fwupd/fwupd/issues/6721
[2]: https://news.ycombinator.com/item?id=7347500
[3]: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=gnutls
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!
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.
The client uses DBUS to ask the server how many bytes were download from your LAN peers (unless you connect your device directly to the internet, then i guess i will show how many bytes ssh probes downloaded from you, inflating their numbers and making them more aggressive on the server feature)
https://github.com/hughsie/passim/blob/ae38c13da1a63fff8c8fa...
https://github.com/hughsie/passim/blob/ae38c13da1a63fff8c8fa...
also, note the quaint code to tell how much carbon it saved earth.
edit: interestingly, if you search for that data collection method name, both ddg and google only find the call from fwmgr side. the actual one, older, from passim code is not shown anywhere
https://duckduckgo.com/?q="passim_client_get_download_saving...
but it's there https://github.com/hughsie/passim/blob/ae38c13da1a63fff8c8fa...
Try `man fwupd.conf` for all the options.
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...
So I would have a backup with a simple password, or even unencrypted in a USB somewhere
This is more secure than using a simple password or (gasp) an unencrypted copy somewhere.
-DWITH_XC_NETWORKING=[ON|OFF] Enable/Disable Networking support (e.g., favicon downloading) (default: OFF)
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...
> IMHO is a downstream maintainer is going to change a package in a way that doesn't have the intent of the upstream project, it should be published under a different name and that maintainer deal with all bug reports caused by their modified version.
the downstream maintainer didn't "change a package in a way that doesn't have the intent of the upstream project", they altered the config flags in one package and made another with the previous flags. the maintainer is being a dick, but not in the way the OP suggested.
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".
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.
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.
https://jblevins.org/log/ssh-vulnkey#:~:text=In%20May%202008....
Those guys are out of control and constantly having conflicts with upstream, I'm astounded to see the amount of support I see for debian in this thread.
I don't think the Debian maintainer is aware that the favicon download feature is optional and manual. You literally need to press a button labelled "Download favicon" before it connects to the internet.
There's some subtle assumptions about ownership in this comment that aren't accurate, insofar as free and open source software is concerned.
FOSS software is not "someone else's" software. They may own the trade mark, but by releasing the software under a FOSS licence, they lose the right to control the direction the software may take. I'm free to copy it, edit it, and redistribute it as I see fit. So are you. So is Debian.
While that sounds like a reasonable argument, I think it misses the fact that you need reasonable usability to get users to use your product. E.g there's no way my wife will use KP of she doesn't have autofill, and she'd then revert to someone else's computer like lastpazs or 1password instead, which I'd argue is a worse solution in all ways possible.
The other thing that makes me question this a little, is removing yubikey support and auto type. While you don't get the full advantage of MFA, having a rotating encryption key is still an additional layer of protection. Meanwhile, without auto type you will need to copy-paste usernames and passwords - and listening to the clipboard is much easier than building a key logger.
I mean, if really what you're looking for is barebones, you can also not use a password manager and come up with a cypher instead.
Instead to create a `keypassxc-offline` package with those tweaks.
If they want to misrepresent your application to Debian users, they'll have to do it under a different name or not at all.
In stark contrast to the previous norm of highly customizable software that catered to both newbies and power users. Right here we see the example of the maintainer unilaterally deciding to strip out a feature that's already been disabled, just because he decided he knows better what KeepassXC users ought to do.
Which is not the case here at all, here downstream turns off a feature in the default build, while simultaneously providing the fully featured version in a just as easily installable package.
I understand it's all volunteer work, I understand it's open source so anyone can add their own custom packaging, on top, but Debian (the OS) certainly uses the ecosystem as a selling point, and it really can come back to bite you.
Iceweasel is full of examples of parts of Firefox removed because the maintainers had personal disagreements on the values of Firefox. Firefox is a fairly privacy-forward browser and Mozilla stand up for a lot of those ideals, and yet Iceweasel pulls features and telemetry on the basis of them being by-definition bad. I think that's a politics/identity statement more than a UX improvement.
I strongly disagree with packagers putting their opinion on top of the software they are packaging, I think packaging should be as pure a translation as is possible for the target system. Now in the case of Iceweasel it could change the branding which I think would give them more leeway to put opinion into it as it's "not Firefox" and there's little risk of users being confused, but I'd also bet that Debian wouldn't accept another pure Firefox packaging because it would duplicate the package in their minds. If that is the case I think that nullifies the idea.
And it's not just features that might change. A Debian maintainer introduced a bug in the OpenSSL random number generator making it insecure, a couple of years ago.
You’re bearing a grudge based on an unintentional bug introduced 18 years ago. Weak take and irrelevant to topic at hand.
Yes it's annoying that an existing behavior will change, but that problem is not more impportant than the problem of what should be the default behavior of a security app.
keepassxc should have always been like that by default and all the added conveniences that also add bug-surface and attack-surface should have always been things you have to go out of your way to add.
It wasn't and so now to fix that error requires a disrupting change, but that is not enough excuse for not fixing the error.
Realistically the most common attack most users face is a phishing attack, removing the browser integration which checks the URL programmatically before filling the password opens the user up to being phished more easily (users check URLs less consistently and less reliably), so arguably this makes the package less secure in the real world.
Odd to just break users by doing this, should have been done with a major release when people expect breakage.
Use Bitwarden (optionally run your own sync server) or Keeper (for less technical people).
2. You can run your own FOSS Bitwarden sync server. It even works airgapped.
I'd say it's really good to have options so the user can choose themselves.
Seems like a good deal /s
Protecting a few dumb people means exposing a lot more people to attack vectors.
I would be shocked if this was true. I have recommended KeepassXC to many of my friends and family and they all use at least one of the features that was in the removed list. To be fair, none of them use debian, but some of them do use other Linux distros.
I don't use debian on desktop anymore on my main machine, but I did use BunsenLabs for a long time and even back then KeepassX (and afterwards KeepassXC) auto-type was a critical feature I used literally every day.
This is not good, it's nonsensical.
All of the disabled features are expendable. I never used any even while they were in there. Yet I do use keepassxc all day every day for the one job it actually does exist to do.
Convenience and necessity are two different things. You want conveninece, and you're not wrong to want it, but you don't need it, and your want of convenience is not important enough to make the base utility when it is a password manager and not a gif editor less safe than it could be by default. It is correct that if you want to trade away safety for convenience, that you have to go out of your way to add that yourself, even if most people will choose to do that, and even if the previous default was backwards and it's now ever so slightly disruptive to correct that error now.
While I'm not opposed to differentiating between a -full and a -minimal version, calling every plugin dangerous by default doesn't make sense.
Is that xkcd of a tiny project doing a lot of heavy lifting.
As for friction leading indirectly to less security through user behavior... how many clicks and how many seconds is it to install the full version? So, yet more bullshit.
And are you putting your passwords on the clipboard in a way that doesn't verify domain names?
Congratulations, you're using insecure methods. Not bullshit.
> Somehow, I have been using the same app without any of those features. So, the idea that the app is not functional or useful without them is bullshit.
Different people might have different needs and wants and other criteria to consider it functional? I think this is not up for you to decide.
But why do they care, right? Most people on their irc channel (that have a basement NAS may I add) agree with their decision.
Now my bet is that your average Debian user does care about convenience. Replacing (default off) selection boxes with different sw packages is acceptable in only a minority of cases, and doesn't seem to be the case here.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529
This was the message from maintainers:
Networking and all plugins have been moved into
the keepassxc-full package.
Feature creep like SSH agent support, browser
integration, Freedesktop.org secret storage,
KeeShare pose undue risks for most users.Making everything copy-paste is bad for security.