Hacker News Reader

Comment by theamk | Hacker News Reader

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

View on HN

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

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.

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.

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.

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

I'm replying just to +1 this as well. This has saved me multiple times not from phishing attacks but from simple mistakes such as entering a password into a HTTP page when the website supports HTTPS.

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.

It's not like the clipboard is secure either. Any arbitrary app can listen to the clipboard in X11, and while it seems harder in Wayland, I'm not sure if I've ever seen a clipboard permission dialog (my Wayland experience is limited though).

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.

With Wayland, the compositor gets to decide which clients to send the "clipboard data available to paste from this file descriptor" event to (wl_data_offer). For example the compositor might only send it to the client whose window is currently focused. So clients that don't receive this event would not have the fd to be able to read from it. Clients that do receive the event can read that data without any restrictions.

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.

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.

> 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

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

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.

Interesting, what are some examples of questionable decisions?

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

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

Features that according to your GP was disabled by default. And according to others in this discussion thread, disabled by default in the upstream also.

If you read the GitHub discussion these features are usually compiled in but not actually exercised until the user enabled then in the UI. The debian packager has changed the compile-time configuration to disable them at compile-time, making them unavailable to the user in the UI. Regardless of the makefile defaults this be a breaking change.

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

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

These are all features that are turned off by default.

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.

Why does everyone keep using this word "plugins"? Quoting the developer:

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

Your conflating PLUG IN technical term with PLUG IN from a users perspective.

No one was really friends with tom on myspace.

>How anyone could see a smaller attack surface as a bad thing on HN baffles the mind.

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.

> How anyone could see a smaller attack surface as a bad thing on HN baffles the mind.

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.

Compile-time flags are by definition not plugins. All optional features were removed indiscriminately.

Can someone make a security related case for disabling autotype?

Yeah that makes no sense, if anything I'd keep autotype and prevent copy password

"If hit by mistake it might autotype in a window that is not at a login prompt, but maybe on a chat session and broadcast the user's password"

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

That's actually reasonable. I use keepassxc, and I have messed the autotype many times. But I mean, that is not an argument for disabling the feature.

I'd assume it would only put the password in a type="password" input, not a random text box.

No, autotype does what it says, it simulates typing keys without looking at the screen

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

Usually SSO means that you have to login just once to access all of your accounts. If it requires you to login multiple times a day then something is not configured correctly.

Well... at my current employer, we have 3 "SSO" providers.

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.

If you can use Firefox, it allows you to create multiple "containers", each with its own set of cookies and other state. You can create a separate container for each Okta login, then you can be logged into all three accounts simultaneously.

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.

I'm in info sec and I agree with you. cyberArk weekly password rotation, no ability to save passwords in Edge, no ability to install a password manager.

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

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.

If I have both enabled in my install, which I specifically chose to, then upgrading the package locks me out of my database, because those features are not compiled.

Jeez, then you simply install the keepassxc-full package and move on. It's not like you store your sudo password in keepass database, too.

but that is part of the problem: this isn't clearly communicated to the end user in the future or present.

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.

How more clearly do you expect it to be communicated?

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.

I've almost never needed to read those news to keep the system working as I want it to. That's the thing.

How would you know in the first place

apt shows the NEWS file during update when there's a change.

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

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

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

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.

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?

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

Intentionally malicious or accidentally vulnerable, vulnerable code is vulnerable code.

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.

Sure it does.

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)

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

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 not worried about xz-style intentional backdoors.

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.

Yet how many people are checking what libraries are being linked on every compilation?

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

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

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

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.

Why does setting build flags constitute a fork?

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

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 ?

Reply on news.ycombinator.com