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

151–160 of 367 posts

Re: KeePassXC Debian maintainer has removed all network features

#151

Post by sangnoir »

Kwpolska wrote: post #149
sangnoir wrote: post #148

Earlier quoted context omitted.

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

Most of HN who've been around know what Bootstrap is (rip, old Twitter). The same rules apply whether your package dependencies are .css, .js or .so

Re: KeePassXC Debian maintainer has removed all network features

#152

Post by Am4TIfIsER0ppos »

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.

Randomly messing with the code they package is the primary job of a debian packager. Which is how we get such great contributions from debian maintainers like the weak keys fiasco.

Re: KeePassXC Debian maintainer has removed all network features

#153

Post by charles_f »

abdullahkhalids wrote: post #77
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.

Can someone make a security related case for disabling autotype?

Yeah that makes no sense, if anything I'd keep autotype and prevent copy password

Re: KeePassXC Debian maintainer has removed all network features

#154

Post by mardifoufs »

barbariangrunge wrote: post #92
thaumaturgy wrote: post #62

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…

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

They don't owe us anything, but that's completely unrelated to the current discussion. They can be completely free to do whatever they want, and users can also disagree with that and voice said disagreement. It's a two way street. Especially in a situation where there's only "one" maintainer per package per distro, meaning that users of the distro (who can be other maintainers too) can disagree with it and openly so. There's a reason why Debian doesn't allow a maintainer to say, gut systemd or switch to another init system unilaterally just because they are volunteering to maintain the package

Re: KeePassXC Debian maintainer has removed all network features

#155

Post by nulld3v »

tuetuopay wrote: post #132
Arnavion wrote: post #29

Earlier quoted context omitted.

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

I'm replying just to +1 this as well. This has saved me multiple times not from phishing attacks but from simple mistakes such as entering a password into a HTTP page when the website supports HTTPS.

Often I'm just browsing along and try to get KeepassXC to autofill a password only to be frustrated when it refuses to work. Then the frustration turns to relief when I go into KeepassXC and see that I've entered "https://website.com" into KeepassXC's URL box causing KeepassXC to only autofill the password on the HTTPS variant of the website and I was on the HTTP variant of the page.

Obviously it's best for the website to just setup HSTS, but I can't fix that for them.

I previously used auto-type and always thought browser extensions were insecure until I realized this.

Re: KeePassXC Debian maintainer has removed all network features

#156

Post by undersuit »

cycomanic wrote: post #143
dannyw wrote: 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.

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

>the alternative to including the yubikey code is not using a yubikey, which reduces security.

The physics of someone cracking my passphrase and the physics of someone cracking my Yubikey are both in the boil the oceans amount of energy.

I'm fine not letting a usb device masquerading as a keyboard have access to my password database.

Remember: "When you lose your YubiKey or someone else gets access to it, your database is not secure anymore."

Re: KeePassXC Debian maintainer has removed all network features

#157

Post by cqqxo4zV46cp »

barbariangrunge wrote: post #92
thaumaturgy wrote: post #62

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…

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 line is always ludicrous because it doesn’t play in literally any other volunteering scenario. In a previous life I coordinated volunteers. You better believe that I still held them to a standard and told them their time was better spent elsewhere if they didn’t want to play by the rules. “But they’re volunteering!” Is a uniquely open source contributor mindset that only seeks to perpetuate some nerd’s weird fiefdom. The reality is that for some people, they’re just…fine not getting paid with money, because what they’re really after is something to control.

Re: KeePassXC Debian maintainer has removed all network features

#158

Post by cqqxo4zV46cp »

Arnavion wrote: post #125
worble wrote: post #79

Earlier quoted context omitted.

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

Users should ideally report bugs to their distribution, not to upstream. The distribution package maintainer then does triage to determine if the issue is specific to the distribution package or should be forwarded upstream. That's how it used to be in the past (and still is for enterprise distros because you might as well use the support contract you paid for). But lately users have gotten more savvy about talking t…

What’s your point? We all know why it’s happening. The reality is that it’s not to user expectations, which is bad.

Re: KeePassXC Debian maintainer has removed all network features

#159

Post by redserk »

theamk wrote: post #133
redserk wrote: post #49

Earlier quoted context omitted.

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

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

You're assuming the flags remove all of the whats-deemed-as-risky behavior.

Trusting the flags from the lens of wanting to trim down a package size? Reasonable.

Trusting the flags from the lens of wanting to boost security? Eh... Crafting a security policy based on compile flags requires a lot of trust towards the developer of the code or spending a lot of time auditing these compile flags.

I just don't see the logic in wanting to simultaneously avoid trusting the code while also placing an enormous amount of new trust in the code's post-compile behavior.

> But features like "fetch favicon from untrusted websites" open huge security holes in case there are ever bugs in http or image libraries.

Image support is still built in, though. You're still susceptible to the vulnerable image library. Just because you're now pulling the images by hand doesn't make it any more secure.

With these concerns users should be considering some form of sandboxing. Whether it's tossing the package in a network-restricted container, VM, or separate device. This is very close to dogmatic security theater.

Re: KeePassXC Debian maintainer has removed all network features

#160

Post by Spivak »

Brian_K_White wrote: post #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-surfac…

Debian is somewhat inconsistent with this but it does have precedent for package to be package-minimal and a corresponding full- variant.

Odd to just break users by doing this, should have been done with a major release when people expect breakage.

Post reply on HN