Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

KeePassXC Debian maintainer has removed all network features

fosstodon.org

Post reply on HN
Print view View original

141–150 of 367 posts

Re: KeePassXC Debian maintainer has removed all network features

#141

Post by Arnavion »

tetha wrote: post #36
okl wrote: post #4

Earlier quoted context omitted.

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…

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

You don't have to proactively read it. But when you notice your keepassxc doesn't work as it used to before, that should be a trigger for you to go back and read it, note that it tells you very clearly that the functionality you're missing is now in keepassxc-full, apt-install it, and go on with your life.

Re: KeePassXC Debian maintainer has removed all network features

#142

Post by Kwpolska »

sangnoir wrote: post #131
Kwpolska wrote: post #96

Earlier quoted context omitted.

This isn’t the project maintainer we’re talking about, it’s the Debian package maintainer. Their job is building a working .deb with working software, not randomly messing with it. Users have the right to demand their packages to be trustworthy.

> Their job is building a working .deb with working software If that were was all there is to packaging - upstream developers could do the same job & have their CI/CD pipeline shoot out a .deb file. However, it's not unheard of for package managers to maintain an evolving patchset that changes the default behavior and better integrates the upstream project to the rest of the distribution and its philosophy.

Upstream developers don’t have the time and bandwidth to set up packaging for all distros and versions.

Improving defaults may be fine according to some. Removing major features advertised by the software due to political reasons is not fine.

My software is a victim of Debian maintainers as well: they chose to remove the default theme from our static site generator, because it was built on top of Bootstrap 3, but Debian only shipped Bootstrap 2 at the time in a global package (they also changed the bootstrap 2 theme to use symlinks to the global version). How is this “better integration with the philosophy”?

Re: KeePassXC Debian maintainer has removed all network features

#143

Post by cycomanic »

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

Re: KeePassXC Debian maintainer has removed all network features

#144

Post by Kwpolska »

whoopdedo wrote: post #139
Kwpolska wrote: post #120

Earlier quoted context omitted.

Doing it in response to a single user’s bug report from 2020 that does not provide any rationale other than “network access bad” constitutes randomly messing with packages.

The feature flag is put there by upstream. If they don't want to support non-network installs then why do they even have that lever? That said it probably makes more sense for Debian to package a `keepassxc-nonet` alongside the default `keepassxc` so end users can choose the variant.

If a user wants to build a hardened copy, they are free to do that. Distros should provide a version with standard features that are expected by end users.

Re: KeePassXC Debian maintainer has removed all network features

#145

Post by TehCorwiz »

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.

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

Re: KeePassXC Debian maintainer has removed all network features

#146

Post by ErikBjare »

temac wrote: post #70
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?

That seems entirely fair to me.

Re: KeePassXC Debian maintainer has removed all network features

#147

Post by jdbernard »

cjk2 wrote: post #100
petee wrote: post #81

Earlier quoted context omitted.

But they already had a choice, since the removed options were disabled by default. This really just breaks core functionality that exists and is expected by real users, under the guise of unnamed security risks...theres plenty of disabled options in Linux that are "potential" risks, so its a silly choice.

Hyperbole! $ apt install keepassx $ apt install keepassx-full Choice made.

Let's say that I had the previous version of keepassxc installed and used a Yubikey to protect it. Now when the distro updates, through no actions of my own, I will be locked out of my password DB because the Yubikey extension is no longer compiled in to the version of KeePassXC the distro is shipping under the original name. Yes, this breaks core functionality. How is this a good thing?

Re: KeePassXC Debian maintainer has removed all network features

#148

Post by sangnoir »

Kwpolska wrote: post #142
sangnoir wrote: post #131

Earlier quoted context omitted.

> Their job is building a working .deb with working software If that were was all there is to packaging - upstream developers could do the same job & have their CI/CD pipeline shoot out a .deb file. However, it's not unheard of for package managers to maintain an evolving patchset that changes the default behavior and better integrates the upstream project to the rest of the distribution and its philosophy.

Upstream developers don’t have the time and bandwidth to set up packaging for all distros and versions. Improving defaults may be fine according to some. Removing major features advertised by the software due to political reasons is not fine. My software is a victim of Debian maintainers as well: they chose to remove the default theme from our static site generator, because it was built on top of Bootstrap 3, but Deb…

> My software is a victim of Debian maintainers as well: they chose to remove the default theme from our static site generator, because it was built on top of Bootstrap 3, but Debian only shipped Bootstrap 2 at the time in a global package (they also changed the bootstrap 2 theme to use symlinks to the global version)

As a Debian stable devotee, this seems reasonable to me. If I wanted each package to bring along & manage its own dependencies, I'd use flatpaks.

> How is this “better integration with the philosophy”?

I'm guessing Bootstrap 3 wasn't yet in whatever release/channel your software was being packaged for?

Can't you imagine any possible benefits of not shipping bootstrap v2 and Bootstrap v3? Or do you just disagree with the Debian unstable -> testing -> stable philosophy? Dependency juggling is just one of the issues distro package maintainers have to wrangle with, that upstream maintainers typically don't care about - an upstream project can declare "this version requires the latest glibc", but distro packagers may have to patch around that because the latest version of glibc hasn't been through testing.

Re: KeePassXC Debian maintainer has removed all network features

#149

Post by Kwpolska »

sangnoir wrote: post #148
Kwpolska wrote: post #142

Earlier quoted context omitted.

Upstream developers don’t have the time and bandwidth to set up packaging for all distros and versions. Improving defaults may be fine according to some. Removing major features advertised by the software due to political reasons is not fine. My software is a victim of Debian maintainers as well: they chose to remove the default theme from our static site generator, because it was built on top of Bootstrap 3, but Deb…

> My software is a victim of Debian maintainers as well: they chose to remove the default theme from our static site generator, because it was built on top of Bootstrap 3, but Debian only shipped Bootstrap 2 at the time in a global package (they also changed the bootstrap 2 theme to use symlinks to the global version) As a Debian stable devotee, this seems reasonable to me. If I wanted each package to bring along & m…

We ship a copy of bootstrap within our data files. They could just leave it as-is and have it working. Bootstrap is a CSS/JS library, there is no global /usr/lib to be concerned about.

Re: KeePassXC Debian maintainer has removed all network features

#150

Post by jdbernard »

pitaj wrote: post #30
theamk wrote: 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…

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.
Post reply on HN