Allow to run without secure storage

[Minoru]

The Problem

Upon startup, Nheko 98533f01d9f39d19d04841a079b6ebe9284559f8 (current master) looks for a Dbus service of KWallet or similar service. When the service is not found, Nheko displays an error message and refuses to start.

I'm not using a DE like KDE or Gnome; I'm running Sway WM on top of a fairly barebones Debian. If possible, I'd prefer not to get pulled into DE ecosystems that provide KWallet or alternatives.

The Solution

Since Nheko worked somehow just a few days prior, I assume KWallet (and similar services) is not the only possible way to store credentials. It'd be nice if Nheko could fall back to its earlier approach if secure storage is not found.

Alternatives

No response

Additional context

No response

Happens in the latest version

• [X] Yes, this feature is still missing.

[deepbluev7]

You can just use KeepassXC and enable the secrets service. The problem is that we otherwise need to store all encrypted messages unencrypted on disk (including the master verification key!). This is a security risk, so we don't want to officially support that. You don't have to use a KDE or Gnome tool, there are a few DE independent alternatives you can use, it just needs to support the secrets API. See here for how to do it with KeepassXC: https://c3pb.de/blog/keepassxc-secrets-service.html

[deepbluev7]

Btw, the earlier approach was just to silently break cross-signing. Now you are explicitly told that stuff is broken, which arguably is an improvement.

[Minoru]

This is an improvement; silent breakage is the worst kind of breakage :) I haven't yet tried the KeepassXC trick, I'll write back once I did (within a couple of days hopefully). Thanks for the answers!

[Minoru]

Upon some investigation, I decided it's easier for me to use gnome-keyring, since it's automatically started by GDM3 (which I use).

I can successfully connect to gnome-keyring-daemon using Seahorse and manipulate it using secret-tool (CLI), but when I start Nheko bf9601018d4b36b654b0febc4af327404541e527, I still get the "Failed to connect to secret storage" error. The logs are:

[2021-09-03 15:07:40.250] [ui] [info] Restoring window size 1920x1033
[2021-09-03 15:07:40.490] [ui] [debug] Profile requested
[2021-09-03 15:07:40.603] [ui] [debug] Status changed to 1
[2021-09-03 15:07:40.629] [db] [error] Restoring secret 'm.cross_signing.master' failed (7): Unknown error

Any ideas on what I can do to fix this?

[deepbluev7]

Are you using the flatpak? Because that seems to have some bug that prevents it from using Gnome Keyring, I'm still investigating that.

[Minoru]

Nope, I'm building an ordinary executable from source on Debian stable, configuring it as follows:

cmake -S. -Bbuild -DHUNTER_ENABLED=ON -DBUILD_SHARED_LIBS=OFF -DUSE_BUNDLED_BOOST=OFF -DUSE_BUNDLED_SPDLOG=OFF -DUSE_BUNDLED_OLM=OFF -DUSE_BUNDLED_GTEST=OFF -DUSE_BUNDLED_CMARK=OFF -DUSE_BUNDLED_JSON=OFF -DUSE_BUNDLED_OPENSSL=OFF -DUSE_BUNDLED_MTXCLIENT=ON -DUSE_BUNDLED_LMDB=OFF -DUSE_BUNDLED_LMDBXX=ON

(basically: I installed some packages and ordered CMake to use those, but I also rely on a few bundled dependencies and Hunter)

[deepbluev7]

Hm, I think I need to setup a VM to debug that.

[Minoru]

It might be something about my setup. After all, I'm not running a DE. Perhaps you could add more logging (on a separate branch)? I can compile and run that, maybe that'll give you some hints.

[deepbluev7]

We are already logging everything we get from https://github.com/frankosterfeld/qtkeychain Would need to modify that library to fix that.

[deepbluev7]

What Debian version are you on? Can you maybe try using the bundled QtKeychain version? There might have been issues with older versions of that library. (Or maybe the newer version at least logs something reasonable, if the Debian version is outdated)

[Minoru]

I'm running Debian 11 (stable), and I'm already using bundled QtKeychain. Just to make sure, I ran make clean, then re-run cmake as above plus -DUSE_BUNDLED_QTKEYCHAIN=ON, but the problem persists.

[deepbluev7]

Okay, thanks for the info, I will dig further!

[regnarg]

Could you add unencrypted option at least via environment variable / CLI switch? For some users, e.g. those who have full disk encryption, using services like Gnome Keyring is an unnecessary annoyance. Also, for example on my system, gnome keyring is notoriously unrealiable and has several times "forgotten" everything stored in it. That is not something you want to happen to your encryption keys.

[rnhmjoj]

So, since no one is working on this here's my attempt at it. I tested that the login persists after restarting nheko, but I haven't tried encryption, yet.

Disclaimer: I have no idea what I'm doing. If it makes sense to you, I'll open a PR.

[deepbluev7]

I think the more sensible approach is to just redirect the secrets functions to QSettings in that case. I.e. replace these ~4 functions to write to the settings file instead: https://github.com/Nheko-Reborn/nheko/blob/master/src/Cache.cpp#L350

[mlochbaum]

I also found this requirement to be a major difficulty. This is particularly frustrating because I use Matrix almost exclusively for unencrypted public rooms and would be fine switching to Element for private chats.

I use Arch Linux without a DE. I was apparently unable to set up KWallet, as I followed the instructions for kwallet-pam on the Arch Wiki and Nheko still didn't open. It doesn't list any diagnostics that I might use to investigate. After spending close to an hour following the confusing and incomplete KeepassXC instructions linked above (I had to look through the other page from "sources" as well as there are major gaps, and never got any output from secret-tool), I found that I could run Nheko, but only with a KeepassXC GUI window open. The cli doesn't do it! That makes for an unpleasant startup process.

Is there an easier way I've missed, or some other misunderstanding here? With this sort of experience I could never recommend Nheko for general use. Any of the following solutions would work for me: start up if secrets are unavailable but refuse to open encrypted rooms; allow configuration to store secrets as plaintext; clear and correct instructions on how to set up a secret service that starts on login.

[deepbluev7]

@mlochbaum Every other distro ships a secrets service out of the box. It is part of the Arch mentality to not do that, but that also means you have to deal with the fallout. KWallet and gnome keyring work fine on Arch, I don't know, why it doesn't for you. Maybe you didn't set the plasma variable to make qtkeychain select the kwallet backend. KeepassXC's support for the secrets API is very new and before 2.7.0 very incomplete.

For the general public Nheko will automatically use the secrets service and work fine. Because every OS under the sun has set them up correctly by default. It is just the more niche Linux distros, that don't do that. If people use Ubuntu, Fedora, Haiku, Windows or macOS, they don't need to do anything and they will get a safe experience by default.

[mlochbaum]

You have an Arch linux entry in the README; I think it would be best to at least include a note that on many systems this is insufficient. It's not nice to have this sprung on you after a 20 minute build! Maybe it's possible to handle this with the right dependencies; if so the AUR package is in error to not include them. My programming language's server has many users of niche distros like Arch, Alpine, and nix (do the other two support secrets out of the box?). So it does seem that I can't recommend Nheko.

I'm confused about why you'd be unwilling to work around this even if it would be better handled by the distro. I don't think the options I gave should be difficult, or compromise Nheko's integrity. Instead it feels like I am being punished because my distro (which I have no control over, and can't easily switch from!) makes it difficult to set up a feature that I'm not even interested in using.

[rnhmjoj]

I think the more sensible approach is to just redirect the secrets functions to QSettings in that case. I.e. replace these ~4 functions to write to the settings file instead: https://github.com/Nheko-Reborn/nheko/blob/master/src/Cache.cpp#L350

Thanks for the suggestion. I'm working on this right now and will report back once I get some results.

[deepbluev7]

You have an Arch linux entry in the README; I think it would be best to at least include a note that on many systems this is insufficient. It's not nice to have this sprung on you after a 20 minute build! Maybe it's possible to handle this with the right dependencies; if so the AUR package is in error to not include them. My programming language's server has many users of niche distros like Arch, Alpine, and nix (do the other two support secrets out of the box?). So it does seem that I can't recommend Nheko.

I'm confused about why you'd be unwilling to work around this even if it would be better handled by the distro. I don't think the options I gave should be difficult, or compromise Nheko's integrity. Instead it feels like I am being punished because my distro (which I have no control over, and can't easily switch from!) makes it difficult to set up a feature that I'm not even interested in using.

Because fixing that is not easy and I don't have an infinite amount of time. I develop this in my free time after work and university in the evening. So I can't "just implement" anything that sounds easy. Just adding a password prompt or just storing the secrets in the config file is not enough. You also need to properly handle the case, where someone accidentally broke their secrets service, so you need to store a flag for every profile, where the secrets are currently stored and provide appropriate error messages. Those things are all solveable, but it is not trivial, adds complexity and I simply don't have time for it. Someone else might fix it, @rnhmjoj seems to be working on it even. But even on Arch it will work out of the box for many users. If you install KDE or Gnome, it should work properly out of the box, unless you try to minimize dependencies. I don't think I need to mention in the README, that on Arch some things might not work, if you don't configure them. I always thought that is how Arch works and one could assume someone who chooses that distro to know that, but I might be wrong. Build times should also not be 20 minutes, if you configured your system properly: https://wiki.archlinux.org/title/Makepkg#Parallel_compilation

If you feel that the PKGBUILD should have more dependencies, feel free to open a discussion on the PKGBUILD. If you think the README should be more explicit, I am open for concrete suggestions. I don't use Arch, so I don't really know what would be appropriate, but I think @redsky17 or @Thulinma should know.

[mlochbaum]

Of course I respect that you know how difficult things are better than I do, and I'm sorry for implying you don't want to help if this isn't the case. The features you mentioned don't seem connected to the technical workarounds I gave? Those are, first, to defer any error message about secrets until an encrypted chat is opened, and second, to allow some configuration that restores the old behavior, presumably with a warning that it's unsafe. The decision is yours of course; I'm only registering that the current situation doesn't work for me.

In my experience it's unusual to install an Arch/AUR package and have it fail to work; if this happens it's almost always because the package is out of date. Some more system-level packages often don't do anything without configuration, and in this case the Arch Wiki page for these describes what you have to do to enable them. A note that Arch users without a DE must make sure KWallet or Gnome Keyring is set up properly would serve this purpose, and I can PR such a note. Quite possibly I've made some error that breaks KWallet, but with no indication that there's a way to debug it and other options that don't require a secret server available I'm not going to look into this further.

[basiliscos]

The problem is that we otherwise need to store all encrypted messages unencrypted on disk (including the master verification key!).

It would be nice to have an option "I know what I'm doing": I already have my notebook in secure environment, and "intrusive security" is a bit annoying. There could be big red alert button, but it would be nice to have that option.

(I want just to ask a few support questions on matrix channels, so, I don't want to have full-powered security. I plan no to have secrets)

[deepbluev7]

I guess putting a flag for "I know this is insecure, do it anyway" in the config file, that is never exposed to users could work.

[basiliscos]

Yep, thank you!

[Minoru]

Thanks @rnhmjoj for fixing this! A bit of docs to explain how this works: edit ~/.config/nheko/nheko.conf to add the following:

[General]
run_without_secure_secrets_service=true

Then launch Nheko, and it won't check for a secrets service.

Keep in mind that your secrets are now in a plain text file, unprotected and easy to steal.

[rnhmjoj]

There's nothing that stops you from writing a daemon that implement the secret service api while using pass or gpg to store the secrets in a text file. In fact, I've just found out about this program when typing this message.