KeePassXC Debian maintainer has removed all network features • Hacker News Board

Re: KeePassXC Debian maintainer has removed all network features

#61

Post by Dah00n » Fri, May 10, 2024, 5:15 PM UTC

fallingsquirrel wrote: post #23

donio wrote: post #8

Earlier quoted context omitted.

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

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…

>If Debian shipped a Linux kernel point release that disabled networking

That is not comparable. "If Debian shipped a Linux kernel point release that removed a risky networking plugin and some disabled-by-default plugins and made a -full version" that would be comparable.

Re: KeePassXC Debian maintainer has removed all network features

#62

Post by thaumaturgy » Fri, May 10, 2024, 5:15 PM UTC

dannyw wrote: post #52

alyandon wrote: post #27

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.

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.

Re: KeePassXC Debian maintainer has removed all network features

#63

Post by tdb7893 » Fri, May 10, 2024, 5:17 PM UTC

dannyw wrote: post #52

alyandon wrote: post #27

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.

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.

Re: KeePassXC Debian maintainer has removed all network features

#64

Post by dataflow » Fri, May 10, 2024, 5:18 PM UTC

dannyw wrote: post #52

alyandon wrote: post #27

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.

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

Re: KeePassXC Debian maintainer has removed all network features

#65

Post by Dah00n » Fri, May 10, 2024, 5:18 PM UTC

JohnTHaller wrote: post #12

bananapub wrote: post #5

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 .

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

Use JohnTHallerNix and it can be. Debian is again taking care of their users. Unlike upstream, Which isn't new. Did he do it in the best way? No. Did he do the right thing? Absolutely.

Re: KeePassXC Debian maintainer has removed all network features

#66

Post by tdb7893 » Fri, May 10, 2024, 5:20 PM UTC

Dah00n wrote: post #51

alyandon wrote: post #27

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.

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

Re: KeePassXC Debian maintainer has removed all network features

#67

Post by jchw » Fri, May 10, 2024, 5:20 PM UTC

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.

Re: KeePassXC Debian maintainer has removed all network features

#68

Post by fallingsquirrel » Fri, May 10, 2024, 5:21 PM UTC

Dah00n wrote: post #56

charles_f wrote: post #33

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…

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.

Re: KeePassXC Debian maintainer has removed all network features

#69

Post by Brian_K_White » Fri, May 10, 2024, 5:23 PM UTC

brnt wrote: post #24

chomp wrote: post #20

Seems like a positive change to me.

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

Re: KeePassXC Debian maintainer has removed all network features

#70

Post by temac » Fri, May 10, 2024, 5:24 PM UTC

alyandon wrote: post #27

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…

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