Live data from Hacker News

KeePassXC Debian maintainer has removed all network features

fosstodon.org

71–80 of 367 posts

Re: KeePassXC Debian maintainer has removed all network features

#71
post #56

Earlier quoted context omitted.

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…

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

No one was really friends with tom on myspace.

Re: KeePassXC Debian maintainer has removed all network features

#72
post #52

Earlier quoted context omitted.

The role of a maintainer is more than copying and pasting upstream. They are allowed to exercise their judgement in what they believe is appropriate for end users of a distribution. In this case, there does seem to be reasonable security justifications for it, and an alternative is provided.

If both upstream and a significant portion of users strongly disagree with a maintainer's judgement, then how is their role as maintainer justified? It's KeePassXC's job to secure the software and produce features that fulfill users' needs as they see fit. Julian's role as maintainer may intersect with that to a limited extent , in deciding on what kind of defaults best fit the rest of the OS. But, in this case, the…

I think you'd have to actually ask the users about that. Not make assumptions based on some loud people on a Mastodon thread. What the user is given here is a choice.

Re: KeePassXC Debian maintainer has removed all network features

#73
post #56

Earlier quoted context omitted.

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…

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

Re: KeePassXC Debian maintainer has removed all network features

#74
post #56

Earlier quoted context omitted.

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…

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

Re: KeePassXC Debian maintainer has removed all network features

#75
post #24

Earlier quoted context omitted.

They disabled all plugins, not just those that may access networks. This is not good, it's nonsensical.

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 w…

Absolute security means you can't do anything. Too much security friction can easily lead to *much more insecure* workarounds.

Re: KeePassXC Debian maintainer has removed all network features

#76
post #42
post #9

Earlier quoted context omitted.

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/keepassx…

That Canonical guy is not coming off brilliantly there. I appreciate that reasonable people can disagree on the best way to package this, but these kind of strong absolute statements – together with calling useful features "misguided" and "crap" – is not great, to put it mildly. I'm pretty sure some compromise could theoretically be reached here. But not with that attitude. "It is our responsibility to our users to p…

What's the alternative to Debian / Ubuntu now that CentOS is gone?

Re: KeePassXC Debian maintainer has removed all network features

#77
post #15

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 n…

He removed not only networking but support for yubikey, and autotype. These are all features that are turned off by default.

Can someone make a security related case for disabling autotype?

Re: KeePassXC Debian maintainer has removed all network features

#78
post #51

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…

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.

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.

Re: KeePassXC Debian maintainer has removed all network features

#79
post #72

Earlier quoted context omitted.

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…

I think you'd have to actually ask the users about that. Not make assumptions based on some loud people on a Mastodon thread. What the user is given here is a choice.

Well no, what the user is actually being given is a completely different application than the original one they downloaded, which is now increasing the maintenance burden upstream because THEY are they one getting all the bug reports because Debian decided to swap the packages out from underneath their users:

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

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

Re: KeePassXC Debian maintainer has removed all network features

#80
post #52

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…

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.

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.

Post reply on HN