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

131–140 of 367 posts

Re: KeePassXC Debian maintainer has removed all network features

#131

Post by sangnoir »

Kwpolska wrote: post #96
barbariangrunge wrote: post #92

Earlier quoted context omitted.

Sorry, why do maintainers owe us anything? They’re typically unpaid or poorly paid and are doing everyone a favour. The code is open source and anyone who doesn’t like their work can easily fork the project. They don’t need to justify anything to us

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.

Re: KeePassXC Debian maintainer has removed all network features

#132

Post by tuetuopay »

Arnavion wrote: post #29
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…

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

Re: KeePassXC Debian maintainer has removed all network features

#133

Post by theamk »

redserk wrote: post #49
josephcsible wrote: post #43

Earlier quoted context omitted.

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)

Re: KeePassXC Debian maintainer has removed all network features

#134

Post by DDiggler »

Meanwhile in Arch land (possibly other distros as well), the fwupd package (which I imagine to be a fairly common package to be installed among the user base) has been silently configured to depend on passim, which spins up an open web server on 0.0.0.0:27500[1] without any(!) explicit user consent whatsover. Passim then uses GnuTLS, which is famous for containing more holes than Swiss cheese [2][3].

Absolutely insane to me, and I would not be surprised if there's an xz type of exploit hidden somewhere in the chain.

[1]: https://github.com/fwupd/fwupd/issues/6721

[2]: https://news.ycombinator.com/item?id=7347500

[3]: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=gnutls

Re: KeePassXC Debian maintainer has removed all network features

#135

Post by WorldMaker »

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.

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

That's what some users seem to want today. It's why both Flatpak and Snap exist with the goals of letting upstream developers just CI/CD spit out a "universal" package for Linux and getting a more "Mac-like" (or "Windows-like" if you prefer) install experience with less waiting for package maintainers to get around to publishing upstream changes.

Admittedly, Flatpak and Snap aren't universally beloved either, yet, but the balance of what the job for a distro's package maintainers should be is definitely in shift.

Re: KeePassXC Debian maintainer has removed all network features

#136

Post by tuetuopay »

So in the end they reduced the attack surface for a program running on your computer by increasing the attack surface on the meatbag operating the computer? (i.e. browser integration which is the only effective thing against phishing)

Seems like a good deal /s

Re: KeePassXC Debian maintainer has removed all network features

#137

Post by WorldMaker »

Kwpolska wrote: post #120
g1sm wrote: post #118

Earlier quoted context omitted.

He wasn’t randomly messing with it, there was a bug report about this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529

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.

You doubt that bug poster's "belief" that "most people want" that change?

Re: KeePassXC Debian maintainer has removed all network features

#138

Post by lawn »

From a KeePassXC maintainer:

> In the lead up to this thread I received three reports of this new package method crippling people's workflow. One report was a user who couldn't open their database anymore because the yubikey feature was removed. Let that sink in for a second. People who lose access to their most important secrets can sometimes do irrational things in the moment of panic.

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

Re: KeePassXC Debian maintainer has removed all network features

#139

Post by whoopdedo »

Kwpolska wrote: post #120
g1sm wrote: post #118

Earlier quoted context omitted.

He wasn’t randomly messing with it, there was a bug report about this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529

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.

Re: KeePassXC Debian maintainer has removed all network features

#140

Post by yjftsjthsd-h »

PlutoIsAPlanet wrote: post #2

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.

> and that maintainer deal with all bug reports caused by their modified version.

I appreciate that it often doesn't happen, but that's supposed to be the default flow regardless: If you're using a distro-provided package and hit a bug, you're supposed to open a bug report against the distro package, and then the maintainer looks at it, and if the bug came from upstream then they file a bug with the upstream project. This is helpful because 1. the package maintainer is probably familiar with the package and can provide initial triage/analysis, possibly even being able to fix the bug outright before going upstream to share the fix, and 2. as you note, distro packages frequently carry some amount of patching and the maintainer should verify whether the bug is in their packaging or the upstream source code.

Unfortunately, many users default to reporting upstream first:( So in practice this is a concern, but it's really not supposed to be.

Post reply on HN