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

171–180 of 367 posts

Re: KeePassXC Debian maintainer has removed all network features

#171

Post by rcxdude »

JeremyNT wrote: post #117
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.

Maybe Debian maintainers consider it their role to do this, but that's absolutely not true in other distributions (e.g., one reason I use Arch is to avoid such tinkering). Down this road lies problems with incompatibilities and new bugs that are distro-specific. As a user it defies my expectations to have software modified to remove functionality and retain the same name. This is a bit too opinionated for my tastes.

This. As a user and a developer I've had more than a few run-ins with a distro deciding to be a bit different, usually with no very weak justification (pedantic interpretations of some standard, attempts to make something 'neat', or just random changes that someone thought would be cool). Debian is especially bad at this, Arch tends to be better but they've also done some stupid things (python-as-python3 being a thorn in so many developer's side for years).

Re: KeePassXC Debian maintainer has removed all network features

#172

Post by SAI_Peregrinus »

TheChaplain wrote: post #166

What is the big issue? The maintainer put up two packages, one stripped down and another with full functionality. I'd say it's really good to have options so the user can choose themselves.

They made the default the stripped-down one, which removes security features like the anti-phishing prevention in the browser extension.

Re: KeePassXC Debian maintainer has removed all network features

#173

Post by Kwpolska »

cassianoleal wrote: post #162
Kwpolska wrote: post #149

Earlier quoted context omitted.

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.

> because it was built on top of Bootstrap 3, but Debian only shipped Bootstrap 2 at the time in a global package > there is no global /usr/lib to be concerned about Aside from possibly the path being different, which is of no concern, how can the 2 above sentences reconcile with each other?

It is trivial to make the Bootstrap 3 global package install into a different folder than Bootstrap 2. It isn’t so trivial for shared libraries without different sonames, for example.

Re: KeePassXC Debian maintainer has removed all network features

#174

Post by undersuit »

lawn wrote: post #161
undersuit wrote: post #156

Earlier quoted context omitted.

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

> When you lose your YubiKey or someone else gets access to it, your database is not secure anymore. You don't store your password on the YubiKey, you use it as a second factor in addition to your password. Do you know what a YubiKey is when you argue against it?

You can add different kinds of authentication to your password safe. I use a password and a key file. You can use just the Yubikey just like you can also have no encryption applied to the password safe.

Re: KeePassXC Debian maintainer has removed all network features

#175

Post by undersuit »

valicord wrote: post #167
undersuit wrote: post #156

Earlier quoted context omitted.

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

What is the physics of someone sniffing your passphrase with a keylogger?

The same as someone sniffing the Yubikey communications.

Re: KeePassXC Debian maintainer has removed all network features

#176

Post by theamk »

redserk wrote: post #159
theamk wrote: post #133

Earlier quoted context omitted.

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

I am not worried about xz-style intentional backdoors.

I am worried about unintentional bugs which end up being remotely exploitable.

So while making sure the image library is bug-free is practically impossible, it is pretty easy to check for compile-time feature flags. Build it once, then ldd to make sure the http library is not linked. Or check debug messages. Or objdump and make sure method is missing. Tons of very simple methods.

From this standpoint, disabling favicon fetching is a 100% effective mitigation for all remote attacks. I've never bothered uploading favicons by hand, and I've never needed any images in my notes.

No security theater, just a pragmatic view.

Re: KeePassXC Debian maintainer has removed all network features

#177

Post by valicord »

Brian_K_White wrote: post #69
brnt wrote: post #24

Earlier quoted context omitted.

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

Removing browser integration and auto-type doesn't increase security, it reduces it by exposing users to clipboard sniffing attacks and phishing websites.

Re: KeePassXC Debian maintainer has removed all network features

#178

Post by valicord »

undersuit wrote: post #175
valicord wrote: post #167

Earlier quoted context omitted.

What is the physics of someone sniffing your passphrase with a keylogger?

The same as someone sniffing the Yubikey communications.

except yubikey communications are not static, so unlike password, sniffing it doesn't allow attacker to open all future versions of the db

Re: KeePassXC Debian maintainer has removed all network features

#179

Post by Arnavion »

accoil wrote: post #168
nulld3v wrote: post #155

Earlier quoted context omitted.

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…

It's not like the clipboard is secure either. Any arbitrary app can listen to the clipboard in X11, and while it seems harder in Wayland, I'm not sure if I've ever seen a clipboard permission dialog (my Wayland experience is limited though). Turning off the browser intergation means that the user may accidentally auto-type into the wrong website. Turning off auto-type means that external applications can see the pass…

With Wayland, the compositor gets to decide which clients to send the "clipboard data available to paste from this file descriptor" event to (wl_data_offer). For example the compositor might only send it to the client whose window is currently focused. So clients that don't receive this event would not have the fd to be able to read from it. Clients that do receive the event can read that data without any restrictions.

That said, this ends up also making this like clipboard managers or wl-paste not work, so there is a wlroots protocol (wlr_data_control) that lets the client know about all data offers. How is a malicious process prevented from being a client of this interface (or even should a process be prevented...) depends on the compositor.

Re: KeePassXC Debian maintainer has removed all network features

#180

Post by redserk »

theamk wrote: post #176
redserk wrote: post #159

Earlier quoted context omitted.

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

I am not worried about xz-style intentional backdoors. I am worried about unintentional bugs which end up being remotely exploitable. So while making sure the image library is bug-free is practically impossible, it is pretty easy to check for compile-time feature flags. Build it once, then ldd to make sure the http library is not linked. Or check debug messages. Or objdump and make sure method is missing. Tons of ver…

Yet how many people are checking what libraries are being linked on every compilation?

CMakefiles are susceptible to bugs too. KeepassXC could also very well remove these build flags and people would be none the wiser.

As I said, concerned users should look at other ways to isolate the application’s behavior here instead of relying on the build process.

Run it in an isolated network namespace if network connectivity is the prevailing concern.

Post reply on HN