Keepassxc: Don't hard depend on dbus

[trilean]

Currently, KeePassXC (but not KeePassX) requires dbus as a hard depenency.
This should be an optional dependency IMO. There are some folks out there running a dbus-less system (it's quite easy on Gentoo actually).

The only thing I've seen that requires dbus is the ScreenLockListener. Can you make that optional?

I tried (and almost succeeded) to shoehorn it into building without dbus. It did compile, but doesn't run (segfaults).

Thanks!

[phoerious]

We also need DBus for mandatory global menu workarounds on Ubuntu, so we can't make it optional. I'm sorry.

[trilean]

I meant as a build-time dependency. So for anyone who wants this feature (and Ubuntu) nothing changes.

I have a preliminary patch that introduces a WITH_SCREENLOCK flag. It compiles & runs without linking to (qt)dbus, albeit tested so far only on a system with DBus installed. It's not quite finished, but if it's ok with you I'll send you a pull request when I'm done.

[phoerious]

The "feature" is a working menu instead of no menu. I would consider that pretty important.

But honestly, I don't really see the point of supporting DBus-less systems. Usage of DBus will rather increase than decrease. It's a core component of modern Linux systems. You wouldn't ask for such a thing on other platforms.

[brokensh3ll]

Usage of DBus will rather increase than decrease.

This is higly incorrect, dbus less system aren't going to disappear or decrease in anyway. The point of a Dbus-less system is to increase the security of the system, you can check on Google why dbus is major source of vulnerability. I was using dbus before and keepassxc as well, I do use now the original keepassx which allow to be build without dbus, no matter if it isn't updated for a decate, as long it is more secure, that is all matter.

[phoerious]

Modern operating systems rely heavily on IPC subsystems and even if DBus may not be the solution we will use in five or ten years time, it will be something else that does this job. And if you think in terms of containerization and isolated execution, IPC layers will become even more important, because applications cannot communicate with each other directly anymore. So no, DBus-less systems are not the future.

[TheZ3ro]

@brokensh3ll using an outdated program and saying that is "more secure" doesn't really make sense.
the Linux kernel is a major source of vulnerability, should we stop using it as well?

IMHO we can re-introduce the -WITH-DBUS flag, enabled by default but I don't really see many people using it.

[phoerious]

The most secure computing method is still manual slide rules. Maybe we should all resort to that in the future. ;-)

[brokensh3ll]

Folk, let's keep this talk in a constructive way. I'm complaining since I moved from glibc to musl and keepassxc is the only app that I used for years that I could not make it work on my system.

As trilean pointed out, hard depending on dbus put people away like him and me to use keepassxc.

Modern operating systems rely heavily on IPC subsystems

I will share you a link to make it short about dbus / systemd since I haven't the streight to make a debate on this awful thing

https://suckless.org/sucks/systemd/

And about a modern and secure system that doesn't rely on all those craps

https://wiki.gentoo.org/wiki/Project:Hardened_musl

The library C musl isn't compatible with dbus (and that's fine). For example, Firefox, PyQt5 or even the horrible glibc offer the build with dbus as optional, why Keepassxc could not ? This is being lazy and no argument can justify the requirement of dbus for this, especially the security one.

Now dbus / glibc / systemd or those fancy mordern stuff are definitively useful on my ubuntu / steam gaming / video watching laptop since I have a little care about the security for it.

using an outdated program and saying that is "more secure" doesn't really make sense.

This is a wrong common sense of security, adding code / features doesn't increase the security at all, especially when it get developed faster than it is audited

In a simple way
https://www.keepassx.org/

Look on the footer, I can see 2018. Moreover as stated on this thread

https://github.com/keepassx/keepassx/pull/206#issuecomment-347005165

The maintainer of keepassx are still available for any security issue, as for today, no security issue is reported and I can't see how it can get worth on the future...

Now if the goal of keepassxc is to be fancy and full of features and designed to work only on fancy modern, mr everybody linux system that's fine, but don't put the argument of security here for god sake.

Ps : If you make dbus as optional again, I will be the first one to emerge it since it is available in the Gentoo portage by default and keepassx is not available anymore. (except on the layman repository which isn't maintened by the dev team of Gentoo). And I just see you accept cryptocurrency as donation which I'm huge fan, will make one if don't hard depend on this virus.

[droidmonkey]

Dude the horse is dead, please stop hitting it with your bat. If you want to remove dbus, absolutely nothing is stopping you (or anyone else) from forking the project and removing it. Everyone has their pet complaint about Linux and makes some awkward distribution that they expect everyone to support. At this time we only provide direct support for the major players (Ubuntu, Debian, Fedora, RHEL, CentOS, Gentoo, and Arch) as they are configured out of the box.

[phoerious]

Sorry, but I cannot take systemd bashing seriously anymore. And as said before, feel free to create hardened builds of KeePassXC.

[brokensh3ll]

KeepassX should work on minimal system for a long time so will stick with it.

another thing, do keepassXC hard depend on qtnetwork ?

I tried with the useflag -http -browser -nework still need qtnetwork, Gentoo ebuild broken or hard dependency ?

Integration of a password manager with a web browser is insecure by design...

For instance
https://www.cvedetails.com/product/15031/Google-Chrome.html?vendor_id=1224

[phoerious]

You can turn off network stuff via cmake. If the Gentoo ebuild doesn't do it, it's a bug in the package definition.
The CVE listing is totally unrelated, though. We are not a browser.

[brokensh3ll]

sigh

A vulnerability inside Google chrome could compromise the credential used with the browser integration of keepassxc it that too hard to understand ? The purpose of a password manager is to keep the password from being stolen.

I'm out of here you guy are clown, I'm aren't sure what are your motivation about keepassxC but advertising it as more secure keepassx is being dishonest. This just win a place in my hard mask package.

[phoerious]

Dude, nobody forces you to use the browser extension. It's a convenience feature. If you don't like it, don't install it. But don't complain about us providing it as an option.