KeePassXC Debian maintainer has removed all network features

https://fosstodon.org/@keepassxc/112417353193348720

by CuriousIndian • 2 years ago

312 337 2 years ago

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.

bananapub3• 2 years ago

not sure why you're commenting without even reading the linked 200 character post?

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

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

milliams• 2 years ago

As stated in the GitHub thread [1]:

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

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

jdbernard6• 2 years ago

The problem is that this will break all existing users who use those features when they update. One of the comments in the GitHub thread has a better path, IMHO: ship two new packages, a -minimal and a -full, and the user to choose, rather than silently break functionality (NEWS is fine, but not really read by user as everyone admits).

JohnTHaller2• 2 years ago

The default package should be named keepassxc-debian-limited or similar and the proper package should be keepassxc

nulld3v5• 2 years ago

But that's not what they disagree with. They are saying you shouldn't have a package called "keepassxc" if it is missing a ton of features from upstream KeepassXC. You should name it something different instead.

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

WesolyKubeczek• 2 years ago

Because I run and upgrade and suddenly all my shit stops working without warning, that's why. It's not how things should be done.

donio• 2 years ago

The WITH_XC_NETWORKING build option is off by default so the developers have obviously intended this to be a valid build configuration.

fallingsquirrel2• 2 years ago

Sure, but that doesn't change the fact that a point release suddenly broke everyone's workflows and is causing maintenance headaches. I don't think the technical minutia of how exactly things were broken is the issue.

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

JohnTHaller2• 2 years ago

Either that or it should indicate to the end user that it's an unsupported package. Maybe showing up as KeePassXC-Debian or KeePassXC-Unsupported and have the developer's contact details (website etc) removed from About and replaced with the Debian details for support.

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

yencabulator• 2 years ago

The default build is networking OFF. Same for Yubikey, browser integration, etc.

    -DWITH_XC_NETWORKING=[ON|OFF] Enable/Disable Networking support (e.g., favicon downloading) (default: OFF)

https://github.com/keepassxreboot/keepassxc/blob/develop/INS...

yjftsjthsd-h5• 2 years ago

and that maintainer deal with all bug reports caused by their modified version.

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

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

HieronymusBosch• 2 years ago

For folks interested this issue on GitHub seems to have the latest comments.

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

okl• 2 years ago

Debian maintainer, Julian Klode, has a "pointed" opinion:

I'm afraid that's not going to happen. It was a mistake to ship with all plugins built by default. This will be painful for a year as users annoyingly do not read the NEWS files they should be reading but there's little that can be done about that.
It is our responsibility to our users to provide them the most secure option possible as the default. All of these features are superfluous and do not really belong in a local password database manager, these developments are all utterly misguided.
Users who need this crap can install the crappy version but obviously this increases the risk of drive-by contributor attacks.

tetha• 2 years ago

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

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

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

ATMLOTTOBEER• 2 years ago

I laughed when I saw this. I once tried to be a hit and run contributor to a project he maintains and I found him to be rude. He is still at it it seems.

Gerlo• 2 years ago

My favorite part is that this guy works at Canonical.

twic• 2 years ago

That is an absolutely mental stance - effective asserting that he knows better than both the developers and users of a piece of software what features it should have! Promote this man to the Debian technical committee immediately, he's perfect.

derkades• 2 years ago

Good discussion here: https://github.com/keepassxreboot/keepassxc/issues/10725

theamk3• 2 years ago

Looks like pretty reasonable decision to me - network features and browser integrations are huge potential holes / exploit entry points. And without network-related features and only running the trusted databases, the tool should be impossible to exploit even if exploits are found, which is a very desirable trait for something as important as password manager. Even original maintainer agrees [1].

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

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

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

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

Arnavion4• 2 years ago

There's one way in which browser integration improves security vs not using it, which is that the browser extension checks the page URL before filling in the credentials, while the approach of manually copy-pasting credentials is vulnerable to typo- and homoglyph-phishing.

JeremyNT2• 2 years ago

This is essential to my own usage of KeepassXC. I never copy/paste from it into a browser and appreciate having this first line defense against phishing.

tuetuopay2• 2 years ago

This. So much this. I don't even understand how browser integrations are not universally thought as a core part of a password manager. With all the phishing that's going along, it's really the last line of defense.

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

pitaj• 2 years ago

Using the term crappy made me immediately lose respect for julian-klode.

jdbernard6• 2 years ago

Particularly of features that users depend on. It really leaves the impression that he thinks very little of debian users.

charles_f4• 2 years ago

He removed not only networking but support for yubikey, and autotype.

These are all features that are turned off by default.

Dah00n4• 2 years ago

They are not "features that are turned off by default" but plugins that are now actually plugins and not built-in features that are turned off. Why on earth would they include plugins that aren't plugged in as a default?

How anyone could see a smaller attack surface as a bad thing on HN baffles the mind. Could he have made a -minimal version? Sure, but the default version should be the clean, secure, without plugins version so he did the right thing.

abdullahkhalids2• 2 years ago

Can someone make a security related case for disabling autotype?

bananenpubs3• 2 years ago

and autotype

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

kiwijamo10• 2 years ago

If it's turned off by default, then please explain the drama. This simple statement makes this drama look like a storm in the proverbial teacup.

n3storm• 2 years ago

Whouldn't be less surprising to publish full app as keepassxc and the other packages be named as -localonly or -partial or -secured or -local-and-secured ?

redserk5• 2 years ago

I'm not sure I really agree here. If there's fundamental concern for the security of a software package, why package the software?

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

josephcsible• 2 years ago

The concern here is accidentally vulnerable code, not malicious code.

arp2424• 2 years ago

Lots of things are a huge potential hole and/or exploit entry point. Lots of these things are also useful.

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

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

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

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

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

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

acters• 2 years ago

I fully agree with you. I wish people would stop focusing heavily on how removing features can potentially decrease attacks. Especially when those exact features are used to prevent the WORST possible attack vector, a mishandled or exploited Clipboard. I do not see how else would a user be able to gain access to the passwords without either using the keyboard, or opening the edit dialogue to select "show password" which would just make them plain-text and MUCH easier to attack. These features were introduced to not only offer ease of use, but to facilitate a more secure method of transferring the password to the desired location. These maintainers clearly did NOT think these things through and potentially created a much less secure package than intended.

worble2• 2 years ago

calling your upstream "crappy"[0] is probably not the most productive way for package maintainer to act

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

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

NikkiA2• 2 years ago

TBF he's a canonical employee, not a debian employee, he's paid to maintain Ubuntu packages, but volunteers for the debian ones, so I'd be more side-eyeing Ubuntu first.

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

strken• 2 years ago

I agree that network features and browser integrations are huge potential holes, but the contributors on the GitHub issue make a very good point when they say that there's minimal testing of the stripped-down build in comparison with the full build, and no testing at all of random combinations of build flags.

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

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

kasabali21• 2 years ago

make a very good point when they say that there's minimal testing of the stripped-down build in comparison with the full build,

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

mikl• 2 years ago

Whether his changes are good or not, it’s still pretty crazy to essentially fork an open source project, but publish your very different version under the same name.

iso8859-1• 2 years ago

Why does setting build flags constitute a fork?

bdd8f1df777b• 2 years ago

I see this kind of mindset often--if we remove the features useful but not perfectly secure from users, we can protect them from such insecurity. But this mindset is wrong. What happens instead is that users will fulfill their needs in even more insecure ways.

kasabali21• 2 years ago

Which more insecure ways? At worst they can install the keepassxc-full package and back to exactly where they were. This isn't tyranny, maintainer has provided a choice.

globular-toast• 2 years ago

Indeed. I use Gentoo and one of the best things is being able to easily switch off features in individual packages like this (or across the whole system, like systemd or X11, for example). But what can a Debian user do? If they're going to build one binary and make it the default it should be the most secure version, not the most featureful.

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

chomp• 2 years ago

Seems like a positive change to me.

brnt• 2 years ago

They disabled all plugins, not just those that may access networks.

This is not good, it's nonsensical.

Brian_K_White4• 2 years ago

Thinking browser or other local integration is not as dangerous as network features is nonsensical.

All of the disabled features are expendable. I never used any even while they were in there. Yet I do use keepassxc all day every day for the one job it actually does exist to do.

Convenience and necessity are two different things. You want conveninece, and you're not wrong to want it, but you don't need it, and your want of convenience is not important enough to make the base utility when it is a password manager and not a gif editor less safe than it could be by default. It is correct that if you want to trade away safety for convenience, that you have to go out of your way to add that yourself, even if most people will choose to do that, and even if the previous default was backwards and it's now ever so slightly disruptive to correct that error now.

alyandon2• 2 years ago

Gutting the functionality that upstream has built into a piece of software and then publishing it under the same name is dubious at best. If they want to go this direction they should publish as a fork under a different name so upstream doesn't get constantly barraged by complaints of users having issues.

This reminds me of the time years ago when the Debian maintainer of Chromium decided to unilaterally disable the ability to install extensions. Thankfully, more pragmatic minded people prevailed and the patch was reverted.

This also reminds me of a time many many many years ago when Debian removed the kernel interface that provided the ability to load binary firmware into network cards and broke networking for me.

Dah00n4• 2 years ago

They didn't "gut what upstream built". He published it without plugins and made a -full version that include plugins. If plugins are plugged in as default it isn't a plugin but a built-in feature. This is the correct way.

tdb78932• 2 years ago

Default plugins is a very common pattern and often what users want. There can be technical reasons but also for common features it's way to have them as opt-out instead of 99% of people needing to opt-in to the same stuff

bananenpubs3• 2 years ago

He published it w/o core package functionality. There are no plugins with KXC, that is one of their main arguments: don't rely on 3rd party code, bring it all inhouse, where it can be checked / maintained.

TehCorwiz• 2 years ago

They're not "plugins". They're compiled in features. The Debian maintainer changed one compile flag and turned off these feature which are disabled by default in the UI anyway. And changing the compile flag didn't remove the options that enable the features from the UI. So, users are very confused why the features they're trying to use don't work. Further, what happens to existing users who had these features enabled and relied on them?

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

dannyw• 2 years ago

The role of a maintainer is more than copying and pasting upstream. They are allowed to exercise their judgement in what they believe is appropriate for end users of a distribution.

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

winternewt• 2 years ago

You can do all that and still honor the points of the parent comment though. I agree that it's poor etiquette to make intrusive changes and hold the original author accountable for them.

thaumaturgy4• 2 years ago

If both upstream and a significant portion of users strongly disagree with a maintainer's judgement, then how is their role as maintainer justified?

It's KeePassXC's job to secure the software and produce features that fulfill users' needs as they see fit. Julian's role as maintainer may intersect with that to a limited extent, in deciding on what kind of defaults best fit the rest of the OS. But, in this case, the developers of the software disagree with his justifications, and reasonable users are also disagreeing with the change.

It seems clear Julian wandered outside his role a bit here.

tdb78932• 2 years ago

Having things named the same across platforms but with significantly different features is a usability nightmare. They even created a package that does have all the same functionality but named it something different, if you're gonna change the functionality from other platforms then that's the one that should have a different name.

dataflow• 2 years ago

The role of a maintainer is more than copying and pasting upstream

They can do that... under a name that doesn't mislead people. Is that so hard?

Gud• 2 years ago

They should not alter basic functionality. Their sole job is to make the software work on their platform.

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

JeremyNT2• 2 years ago

Maybe Debian maintainers consider it their role to do this, but that's absolutely not true in other distributions (e.g., one reason I use Arch is to avoid such tinkering). Down this road lies problems with incompatibilities and new bugs that are distro-specific.

As a user it defies my expectations to have software modified to remove functionality and retain the same name. This is a bit too opinionated for my tastes.

cycomanic• 2 years ago

The justification is absolute rubbish. I The argument is that it reduces attack surface, but compared to what, the alternative to including the yubikey code is not using a yubikey, which reduces security. The alternative to using the browser integration (or the ssh agent) is to use the clipboard, which is likely more code and definitely less vetted code.

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

vilunov• 2 years ago

I don't understand the need of such a role at all. It's fine if it's the OS-level software, but for end-user applications such as KeePass I'd prefer that there would be no intermediaries between the developers of the app and the users. You don't need to repackage every piece of software that your users might want to use, let developers target your OS on their own by providing a stable set of APIs and ABIs, otherwise it's not really an OS.

rfoo4• 2 years ago

Oh no, xscreensaver or GNU Parallel flame war once again.

temac• 2 years ago

If they want to go this direction they should publish as a fork under a different name so upstream doesn't get constantly barraged by complaints of users having issues.

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

ErikBjare• 2 years ago

That seems entirely fair to me.

zer00eyz2• 2 years ago

IF apple said "hey we edited your app because we think its more secure"...

People would have torches and pitchforks out.

But a deb maintainer does it and there is debate?

If there was a security issue then the insecure version should NOT be available. But again this is not the case.

In an App Store world, the role of mainainter has to change. The job is to make the software work with the distro, not keep the name and make some pseudo fork because you want it to be another way.

int_19h2• 2 years ago

Debian does this all the time. There are thousands of .deb packages that are built with patches.

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

Vegemeister• 2 years ago

I've visited the App Store world, and my experience was that, weighted by how often packages appear in search results, the median is charitably described as "potentially unwanted", and honestly described as malware.

out-of-ideas2• 2 years ago

people did not have their pitchforks out for (although not exactly a cve thing) https://daniel.haxx.se/blog/2024/03/08/the-apple-curl-securi...

redeeman2• 2 years ago

flipping build switches that upstream provided is "edited your app" ??

BLKNSLVR• 2 years ago

Isn't this just FOSS working as intended?

There are lots of distributions other than Debian.

kragen3• 2 years ago

lots of debian packages are compiled without some compile flags that enable optional functionality; emacs, for example, comes in emacs-nox, emacs-gtk, and emacs-lucid, the last two of which use two different x-windows toolkits to give emacs a gui. (it's nice to not have to install a gui environment in order to have a text editor, see.) vim similarly has vim-tiny, vim-nox, vim-motif, and vim-gtk3 versions

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

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

It is our responsibility to our users to provide them the most secure option possible as the default. All of these features are superfluous and do not really belong in a local password database manager, these developments are all utterly misguided.
Users who need this crap can install the crappy version but obviously this increases the risk of drive-by contributor attacks.

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

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

netsharc2• 2 years ago

Your points are valid, but doing a switcheroo of someone's software is the stupid part...

You say you trust Debian, but until this update, they've been allowing those horrible horrible shenanigans, on your system!

Would you trust a security guard who for many years didn't notice a part of the building he should've checked for unlocked doors, until someone pointed it out to him?

moqmar• 2 years ago

So the Debian maintainer complains about the upstream project (which they decided to maintain the package for) bringing "crap" and having "utterly misguided" development? And somehow people say that this is the reasonable person here, basing a major change of a software's featureset on such an opinion?

Independent from whether the original change is good or bad, so much of what's wrong with Open Source is people trying to work against each other instead of together...

phoerious• 2 years ago

The extra functionality isn't opening security holes. It is central functionality that users have come to expect such as Auto-Type or support for YubiKeys. The Debian maintainer has decided to disable the WITH_XC_ALL flag, which disables ALL optional features (not sure why you consider this a lie).

Your claim that KeePassXC communicates with random webpages is also false. There are two cases in which websites are communicated with (none of them random): a) an optional update check (can be disabled), b) when you click the button to download a website's favicon. Please don't just state things that are not true.

mikepavone3• 2 years ago

All they did was change the XC_ALL build parameter to OFF [0] which happens to be the default in upstream's CMakeLists.txt [1]. If upstream thinks this functionality is so important maybe they should fix their defaults.

I think it's a bit unfortunate that users of this package may be confused why stuff stops working when they upgrade, but having the unsuffixed package match upstream defaults seems entirely reasonable otherwise.

[0] https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f... [1] https://github.com/keepassxreboot/keepassxc/blob/develop/CMa...

dingensundso• 2 years ago

At first I thought it should be the other way around. Keep the current keepassxc package and create a keepassxc-minimal. But seeing the build options it makes sense to have a keepassxc-full.

Only thing is this will annoy some people when they upgrade. But only when this reaches stable and then there will be notice in the upgrade documentation and apt-listchangea.

c-hendricks• 2 years ago

If upstream thinks this functionality is so important maybe they should fix their defaults.
none of these features are plugins. All of them are built-in functionality that belong to the main product. If anything, we will reduce the number of such compile-time flags in the future, so these things cannot be disabled anymore.

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

out-of-ideas2• 2 years ago

Gutting the functionality that upstream has built into a piece of software and then publishing it under the same name is dubious at best

reminds me of busybox's implementations of: bash, sed, awk, ect and similar situations when folks go and ask 'how something-in bash works' then 'it doesnt work' all because of macos bash vs gnu bash, and forever on the battle goes with naming.

blablabla123• 2 years ago

Kind of interesting actually. In the 2000s/2010s it was quite normal that distributions provided modified packages. Maybe not necessarily function-wise but theming, config files to a degree that interoperability wasn't the best. Even more funny that this is done now by Debian which always had a reputation of providing vanilla packages... But I guess after the xz debacle this is getting a new kind of attention

jdbernard6• 2 years ago

If this was the first time they were packaging keepassxc, this would be fine. If they instead chose to remove the keepassxc package and provide two new packages, keepassxc-minimal and keepassxc-full, it would be fine. It's the fact that the main package that people already have installed will no longer have functionality that many users depend on, breaking their configurations after an update.

vsl• 2 years ago

Debian is the only distro with this weird attitude of disregard towards upstream.

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

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

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

kasabali21• 2 years ago

What was your package named?

2OEH8eoCRo0• 2 years ago

It sounds like a necessary but painful change if we want secure by default.

bananenpubs3• 2 years ago

Speak for yourself, please, not for 'us'.

unparagoned• 2 years ago

People always crap over LastPass, but when you ask them what they do, it’s some elaborate process relying on thousands of no name packages and devs.

lawn5• 2 years ago

These kind of "feature changes" in Debian packages is one reason I stay away from Debian.

And it's not just features that might change. A Debian maintainer introduced a bug in the OpenSSL random number generator making it insecure, a couple of years ago.

wswope• 2 years ago

a couple of years ago

You’re bearing a grudge based on an unintentional bug introduced 18 years ago. Weak take and irrelevant to topic at hand.

charles_f4• 2 years ago

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

While that sounds like a reasonable argument, I think it misses the fact that you need reasonable usability to get users to use your product. E.g there's no way my wife will use KP of she doesn't have autofill, and she'd then revert to someone else's computer like lastpazs or 1password instead, which I'd argue is a worse solution in all ways possible.

The other thing that makes me question this a little, is removing yubikey support and auto type. While you don't get the full advantage of MFA, having a rotating encryption key is still an additional layer of protection. Meanwhile, without auto type you will need to copy-paste usernames and passwords - and listening to the clipboard is much easier than building a key logger.

I mean, if really what you're looking for is barebones, you can also not use a password manager and come up with a cypher instead.

jeffalyanak3• 2 years ago

I think the solution suggested by drawks seems clearly the correct choice:

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

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

Why would this _not_ be the obvious choice?

rfoo4• 2 years ago

Because maintainers have an opinion and explicitly wanted to change the default.

jeffalyanak3• 2 years ago

That does allow you to change the default for users installing the packages and while ensuring that users who already have it installed don't lose functionality during an upgrade.

GorsyGentle• 2 years ago

Perhaps, and that's not unreasonable in and of itself. But to do so in such a user-hostile manner? That's a bit over the top. A new minimal package, advertising it, and only then eventually making it the default would have been far, far more effective.

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

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

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

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

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

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

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

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

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

Liskni_si2• 2 years ago

It not only _is_ the obvious choice, it is _exactly_ what has actually happened in Debian: https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f...

The original post is just a badly written clickbait. Nothing was removed, it was just moved to the keepassxc-full package.

jeffalyanak3• 2 years ago

I don't believe you're correct. It seems like the option that Debian decided on _will_ remove those features for users who are upgrading a package.

Users who already have the keypassxc package will need to explicitly switch packages if they want the full one. That's not the same behaviour as described in my quote comment.

Brian_K_White4• 2 years ago

I think it's correct for the default package to be the safest-possible one. It's a password manager not an mp3 player.

Yes it's annoying that an existing behavior will change, but that problem is not more impportant than the problem of what should be the default behavior of a security app.

keepassxc should have always been like that by default and all the added conveniences that also add bug-surface and attack-surface should have always been things you have to go out of your way to add.

It wasn't and so now to fix that error requires a disrupting change, but that is not enough excuse for not fixing the error.

kernal2• 2 years ago

A password manager with a built-in MP3 player? That's my next project.

Brian_K_White4• 2 years ago

The songs could tell you where to find the post-it note within your record library. Let the hackers gain access to your google drive AND decrypt the db. :)

Latty• 2 years ago

Safest by what metric? Calling the browser integration a "convenience" feature only is just fundamentally wrong.

Realistically the most common attack most users face is a phishing attack, removing the browser integration which checks the URL programmatically before filling the password opens the user up to being phished more easily (users check URLs less consistently and less reliably), so arguably this makes the package less secure in the real world.

Spivak• 2 years ago

Debian is somewhat inconsistent with this but it does have precedent for package to be package-minimal and a corresponding full- variant.

Odd to just break users by doing this, should have been done with a major release when people expect breakage.

aragilar• 2 years ago

Uh, it's only changed in unstable, so it will be a major release when current testing is released.

rfoo4• 2 years ago

Title is wrong. The original post said maintainer has removed ALL features, not only networking features, and this was true, ALL optional features, including entirely offline features, were turned off during build.

jchw• 2 years ago

Considering it would be completely possible to make this distinction without breaking existing users, it's difficult to see this as anything other than a bad decision by the Debian package maintainer. While having the ability to have KeepassXC without networking features is certainly nice, considering the browser integration to be a niche feature is just severely out of touch; I would be willing to place real money on betting that more than half (probably well over half) of users of KeepassXC in Debian today want features that will be surprise-disabled because the maintainer chose a way of doing this that would break existing users to impose their opinion.

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

kernal2• 2 years ago

I like this solution. He reduced the attack vectors in the base application by removing features a large majority of people don't use. And if they want these additional features then download the full version.

nulld3v5• 2 years ago

features a large majority of people don't use.

I would be shocked if this was true. I have recommended KeepassXC to many of my friends and family and they all use at least one of the features that was in the removed list. To be fair, none of them use debian, but some of them do use other Linux distros.

I don't use debian on desktop anymore on my main machine, but I did use BunsenLabs for a long time and even back then KeepassX (and afterwards KeepassXC) auto-type was a critical feature I used literally every day.

gr4vityWall2• 2 years ago

I never knew KeepPassXC could talk with my browser or interact with ssh until I saw this thread, and I've been using it for almost 10 years now.

coppsilgold• 2 years ago

I have already been using bubblewrap[1] to isolate KeePassXC from the network and more (the only access it has is to its own private directory and a hardened Wayland socket[2]). I wouldn't recommend relying on devs or maintainers to do application isolation work for you.

[1] <https://github.com/containers/bubblewrap>

[2] <https://git.sr.ht/~whynothugo/way-secure>

0x_rs2• 2 years ago

I would like to believe package maintainers should operate under a principle of least astonishment and not disable core features (and not plugins, despite currently 25 entries of that word in this comment section) unless there's a documented or at the very least probable risk, none of which seem to be the case here. KeePassXC has many features but none that would on their own, and without explicit user intervention, be a likely source of vulnerabilities. The browser integration must be toggled on before you can even set it up, likewise for (I believe) every other function disabled with this flag, so a -minimal package may have been more appropriate. The small subset of users that could benefit in some indeterminate future from this change must be incredibly small, while it's going to be a serious annoyance for anyone using the browser integration, a function that's generally far safer than clipboard access. It also doesn't feel in line with the project's vision:

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

DDiggler• 2 years ago

Meanwhile in Arch land (possibly other distros as well), the fwupd package (which I imagine to be a fairly common package to be installed among the user base) has been silently configured to depend on passim, which spins up an open web server on 0.0.0.0:27500[1] without any(!) explicit user consent whatsover. Passim then uses GnuTLS, which is famous for containing more holes than Swiss cheese [2][3].

Absolutely insane to me, and I would not be surprised if there's an xz type of exploit hidden somewhere in the chain.

[1] https://github.com/fwupd/fwupd/issues/6721

[2] https://news.ycombinator.com/item?id=7347500

[3] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=gnutls

workethics• 2 years ago

Good to know. I think this should probably be it's own post

1oooqooq5• 2 years ago

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

1oooqooq5• 2 years ago

why fish for fwupd? systemd-resolved which is everywhere, will open (at request) an LLMNR server (a.k.a. mDNS, nee microsoft netbios) on port 5355.

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

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

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

fix for resolved is commented out on /etc/systemd/resolved.conf `LLMNR=no`, and you probably also want `DNSStubListener=no`. heck here is a good default

   ```
   # /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
   ```

1oooqooq5• 2 years ago

looking at the fwupmgr code.

The client uses DBUS to ask the server how many bytes were download from your LAN peers (unless you connect your device directly to the internet, then i guess i will show how many bytes ssh probes downloaded from you, inflating their numbers and making them more aggressive on the server feature)

https://github.com/hughsie/passim/blob/ae38c13da1a63fff8c8fa...

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

AceJohnny2• 2 years ago

mDNS, nee microsoft netbios

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

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

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

hughsient• 2 years ago

since they have a low quality default conf file without commented out defaults

Try `man fwupd.conf` for all the options.

tuetuopay2• 2 years ago

So in the end they reduced the attack surface for a program running on your computer by increasing the attack surface on the meatbag operating the computer? (i.e. browser integration which is the only effective thing against phishing)

Seems like a good deal /s

cyanydeez2• 2 years ago

This reminds me of the how to secure a trashcan from bears in yellow stone: the dumbest person and the smartest bear has significant overlap.

Protecting a few dumb people means exposing a lot more people to attack vectors.

lawn5• 2 years ago

From a KeePassXC maintainer:

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

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

guilhas3• 2 years ago

Everyone using an offline password manager without having a backup might as well consider everything lost

This sounds like emotional blackmail

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

valicord7• 2 years ago

How would a backup help in this scenario? The data is fine, it's the application that stopped working.

TheChaplain• 2 years ago

What is the big issue? The maintainer put up two packages, one stripped down and another with full functionality.

I'd say it's really good to have options so the user can choose themselves.

SAI_Peregrinus• 2 years ago

They made the default the stripped-down one, which removes security features like the anti-phishing prevention in the browser extension.

shmerl• 2 years ago

There was some comment about it. Basically, it's for security reasons. Those who aren't using those features wouldn't expect them to appear (especially sneakily). And those who are planning to use them will figure out what package to install.

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

This was the message from maintainers:

    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.

Dylan168074• 2 years ago

Browser integration and autotype are not feature creep.

Making everything copy-paste is bad for security.

nsajko• 2 years ago

Horrid PR for Debian. The decision is ignorant and capricious and makes Debian seem like a personal toy project instead of a FOSS cornerstone. On top of that the Debian maintainer then responds by calling upstream "crappy".

gradientsrneat• 2 years ago

Said maintainer also does dev work for Canonical. So this probably affects optics for Ubuntu too. Although, speculating charitably, maybe the maintainer knows something we don't about the upstream's security policies.

FdbkHb• 2 years ago

Debian maintainers are experts at touching things they shouldn't and creating a mess in the process. The worst case, by far, was when they broke the RNG of SSH key generation:

https://jblevins.org/log/ssh-vulnkey#:~:text=In%20May%202008....

Those guys are out of control and constantly having conflicts with upstream, I'm astounded to see the amount of support I see for debian in this thread.

cookiengineer• 2 years ago

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

I don't think the Debian maintainer is aware that the favicon download feature is optional and manual. You literally need to press a button labelled "Download favicon" before it connects to the internet.

vbezhenar• 2 years ago

This maintainer does not respect upstream developers. He must step down and pass this package to someone who respects the upstream developers and their judgement. He must not keeping this name hostage and damaging the brand.

gr4vityWall2• 2 years ago

The maintainer's position seems reasonable to me. A different package, compiled with the network features, is provided too. I like this as a default.

xcdzvyn• 2 years ago

Fortunately Debian maintainers have a fantastic track record of writing ad-hoc patches for security-sensitive software.

hi-v-rocknroll3• 2 years ago

I abandoned KeePassX (pre XC fork) when they made wonky changes ~10 years ago.

Use Bitwarden (optionally run your own sync server) or Keeper (for less technical people).

hiAndrewQuinn• 2 years ago

I recently switched from BW to XC in the wake of their acquisition, and I have to admit, the mobile experience is just a little more annoying. But I sleep better at night knowing that I don't keep anything critical on servers I don't own.

hi-v-rocknroll3• 2 years ago

1. What acquisition? https://bitwarden.com/blog/

2. You can run your own FOSS Bitwarden sync server. It even works airgapped.

https://bitwarden.com/help/install-and-deploy-offline/

yawaramin• 2 years ago

A password manager without browser integration is essentially dead in the water. Seems like what they're shipping is unusable for most people. We all know 'unusable FOSS' cliché but in this case it actually applies.

parasti2• 2 years ago

It's crazy the amount of power maintainers hold over someone else's software. This reminds me of the time when Fedora maintainers disabled GLES1 support in Mesa because "nobody should be using it anymore (there are newer OpenGL versions)", disregarding the fact that GLES1 was well and fully maintained upstream, and was and is still the only option on many devices.

YPPH2• 2 years ago

power maintainers hold over someone else's software

There's some subtle assumptions about ownership in this comment that aren't accurate, insofar as free and open source software is concerned.

FOSS software is not "someone else's" software. They may own the trade mark, but by releasing the software under a FOSS licence, they lose the right to control the direction the software may take. I'm free to copy it, edit it, and redistribute it as I see fit. So are you. So is Debian.

parasti2• 2 years ago

That's besides the point. You can do whatever with the software, but it gets muddy when you then release it under the same name as the original. That name may not be trademarked, but it is still not yours to use.

kasabali21• 2 years ago

Not even comparable. Debian users can choose between the stripped and full version of Keepassxc, unlike the MESA example above.

raverbashing• 2 years ago

Hissy-fits like these are one of the reasons there's never going to be a "year of the linux on desktop"

But why do they care, right? Most people on their irc channel (that have a basement NAS may I add) agree with their decision.

Now my bet is that your average Debian user does care about convenience. Replacing (default off) selection boxes with different sw packages is acceptable in only a minority of cases, and doesn't seem to be the case here.

danpalmer2• 2 years ago

We used to deploy on Debian at my previous place, and we hit this sort of shit all the time. Maintainer ripped out features they disagreed with (political reasons, or just engineering/product taste), maintainers changing the configuration files to things that suited them better, etc.

I understand it's all volunteer work, I understand it's open source so anyone can add their own custom packaging, on top, but Debian (the OS) certainly uses the ecosystem as a selling point, and it really can come back to bite you.

rationably2• 2 years ago

Could you provide an example where maintainer "ripped out" a feature because of a strictly political reason?

danpalmer2• 2 years ago

When I say "political" I'm referring more to belief systems, but calling them religious beliefs would be far too antagonistic for the point I'm trying to make.

Iceweasel is full of examples of parts of Firefox removed because the maintainers had personal disagreements on the values of Firefox. Firefox is a fairly privacy-forward browser and Mozilla stand up for a lot of those ideals, and yet Iceweasel pulls features and telemetry on the basis of them being by-definition bad. I think that's a politics/identity statement more than a UX improvement.

I strongly disagree with packagers putting their opinion on top of the software they are packaging, I think packaging should be as pure a translation as is possible for the target system. Now in the case of Iceweasel it could change the branding which I think would give them more leeway to put opinion into it as it's "not Firefox" and there's little risk of users being confused, but I'd also bet that Debian wouldn't accept another pure Firefox packaging because it would duplicate the package in their minds. If that is the case I think that nullifies the idea.

juliangmp• 2 years ago

I have a lot of respect for the Debian project but every now and then one of their maintainers does something completely stupid and unreasonable and expects applause

egberts1• 2 years ago

Should bave left the original KeyPassXC Debian package alone and ...

Instead to create a `keypassxc-offline` package with those tweaks.

Zuiii• 2 years ago

This should have been handled the same way Mozilla handles Firefox. KeepAssXC developers, file for trademark protection and then send a cease and desist to Debian legal.

If they want to misrepresent your application to Debian users, they'll have to do it under a different name or not at all.

willywanker• 2 years ago

I see in this an attitude that's become increasingly common since the 2010s among developers as well as software companies regardless of open source or proprietary - "We know what's good for you, the end user and we will decide on your behalf." and use this as an excuse to strip out features that had been long available. Firefox is a classic example.

In stark contrast to the previous norm of highly customizable software that catered to both newbies and power users. Right here we see the example of the maintainer unilaterally deciding to strip out a feature that's already been disabled, just because he decided he knows better what KeepassXC users ought to do.

kasabali21• 2 years ago

That's a very misleading comparison. When Mozilla (upstream) axes a feature, it's gone permanently and you can't get it back.

Which is not the case here at all, here downstream turns off a feature in the default build, while simultaneously providing the fully featured version in a just as easily installable package.

KeePassXC Debian maintainer has removed all network features

Related Stories