Live data from Hacker News

KeePassXC Debian maintainer has removed all network features

fosstodon.org

41–50 of 367 posts

Re: KeePassXC Debian maintainer has removed all network features

#41
post #13

Earlier quoted context omitted.

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

But it’s a valid build configuration option provided by upstream. Not sure I follow this line of reasoning.

Sure, I think that's a reasonable stance. If upstream agrees that such a configuration is a valid distribution of KeepassXC and can be branded KeepassXC, then that's up to them. I would probably disagree with upstream in that scenario just from a UX perspective, but I would understand both sides.

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

Re: KeePassXC Debian maintainer has removed all network features

#42
post #9

Earlier quoted context omitted.

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 .

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

Re: KeePassXC Debian maintainer has removed all network features

#43
post #40
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…

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.

Re: KeePassXC Debian maintainer has removed all network features

#45

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

Re: KeePassXC Debian maintainer has removed all network features

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

Re: KeePassXC Debian maintainer has removed all network features

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

Re: KeePassXC Debian maintainer has removed all network features

#49
post #40

Earlier quoted context omitted.

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.

Post reply on HN