Could not connect to secure storage

[anoduck]

Describe the bug

Logged into nheko for the first time, really impressed, and it immediately opened a popup window informing me it could not connect to a secure storage provider. It suggested I made sure dbus is running(it is), and that I had a keyring manager installed and running (i do).

So, apparently, it is unable to locate my secure storage provider, and I did not see a way that this could be set within the configuration file.

To Reproduce

1. Open Nheko
2. Enter username and password
3. click login
4. See error

What happened?

Nheko could not connect to the secure storage to save encryption secrets to. This can have multiple reasons. Check if your D-Bus service is running and you have configured a service like KWallet, Gnome Keyring, KeePassXC or the equivalent for your platform. If you are having trouble, feel free to open an issue here: https://github.com/Nheko-Reborn/nheko/issues

Expected behavior

I didn't expect it to be unable to locate my keyring.

Screenshots

Version

0.10.1

Operating system

BSD

Installation method

Some repository (AUR, homebrew, distribution repository, PPA, etc)

Qt version

N/A

C++ compiler

N/A

Desktop Environment

i3

Did you use profiles?

• [ ] Profiles used?

Relevant log output

[2022-09-17 16:45:36.842] [ui] [info] Restoring window size 640x501
[2022-09-17 16:45:36.896] [ui] [info] WebRTC: initialised GStreamer 1.20.3
[2022-09-17 16:45:36.986] [ui] [info] jdenticon plugin not found.
[2022-09-17 16:45:37.693] [ui] [debug] CompletionProxyModel: build trie: 96.600767 ms
[2022-09-17 16:45:37.752] [qml] [warning] qrc:/qml/emoji/EmojiPicker.qml:298:38: QML Image: Binding loop detected for property "sourceSize.height" (qrc:/qml/emoji/EmojiPicker.qml:298, )
[2022-09-17 16:45:37.752] [qml] [warning] qrc:/qml/emoji/EmojiPicker.qml:298:38: QML Image: Binding loop detected for property "sourceSize.height" (qrc:/qml/emoji/EmojiPicker.qml:298, )
[2022-09-17 16:45:37.752] [qml] [warning] qrc:/qml/emoji/EmojiPicker.qml:298:38: QML Image: Binding loop detected for property "sourceSize.height" (qrc:/qml/emoji/EmojiPicker.qml:298, )
[2022-09-17 16:45:37.759] [qml] [warning] qrc:/qml/emoji/EmojiPicker.qml:298:38: QML Image: Binding loop detected for property "sourceSize.height" (qrc:/qml/emoji/EmojiPicker.qml:298, )
[2022-09-17 16:45:37.759] [qml] [warning] qrc:/qml/emoji/EmojiPicker.qml:298:38: QML Image: Binding loop detected for property "sourceSize.height" (qrc:/qml/emoji/EmojiPicker.qml:298, )
[2022-09-17 16:45:37.759] [qml] [warning] qrc:/qml/emoji/EmojiPicker.qml:298:38: QML Image: Binding loop detected for property "sourceSize.height" (qrc:/qml/emoji/EmojiPicker.qml:298, )
[2022-09-17 16:45:37.765] [qml] [warning] qrc:/qml/emoji/EmojiPicker.qml:298:38: QML Image: Binding loop detected for property "sourceSize.height" (qrc:/qml/emoji/EmojiPicker.qml:298, )
[2022-09-17 16:45:37.765] [qml] [warning] qrc:/qml/emoji/EmojiPicker.qml:298:38: QML Image: Binding loop detected for property "sourceSize.height" (qrc:/qml/emoji/EmojiPicker.qml:298, )
[2022-09-17 16:45:37.766] [qml] [warning] qrc:/qml/emoji/EmojiPicker.qml:298:38: QML Image: Binding loop detected for property "sourceSize.height" (qrc:/qml/emoji/EmojiPicker.qml:298, )
[2022-09-17 16:45:37.772] [qml] [warning] qrc:/qml/emoji/EmojiPicker.qml:298:38: QML Image: Binding loop detected for property "sourceSize.height" (qrc:/qml/emoji/EmojiPicker.qml:298, )
[2022-09-17 16:45:37.772] [qml] [warning] qrc:/qml/emoji/EmojiPicker.qml:298:38: QML Image: Binding loop detected for property "sourceSize.height" (qrc:/qml/emoji/EmojiPicker.qml:298, )
[2022-09-17 16:45:37.772] [qml] [warning] qrc:/qml/emoji/EmojiPicker.qml:298:38: QML Image: Binding loop detected for property "sourceSize.height" (qrc:/qml/emoji/EmojiPicker.qml:298, )
[2022-09-17 16:45:37.777] [qml] [warning] qrc:/qml/emoji/EmojiPicker.qml:298:38: QML Image: Binding loop detected for property "sourceSize.height" (qrc:/qml/emoji/EmojiPicker.qml:298, )
[2022-09-17 16:45:37.777] [qml] [warning] qrc:/qml/emoji/EmojiPicker.qml:298:38: QML Image: Binding loop detected for property "sourceSize.height" (qrc:/qml/emoji/EmojiPicker.qml:298, )
[2022-09-17 16:45:37.777] [qml] [warning] qrc:/qml/emoji/EmojiPicker.qml:298:38: QML Image: Binding loop detected for property "sourceSize.height" (qrc:/qml/emoji/EmojiPicker.qml:298, )
[2022-09-17 16:45:37.783] [qml] [warning] qrc:/qml/emoji/EmojiPicker.qml:298:38: QML Image: Binding loop detected for property "sourceSize.height" (qrc:/qml/emoji/EmojiPicker.qml:298, )
[2022-09-17 16:45:37.783] [qml] [warning] qrc:/qml/emoji/EmojiPicker.qml:298:38: QML Image: Binding loop detected for property "sourceSize.height" (qrc:/qml/emoji/EmojiPicker.qml:298, )
[2022-09-17 16:45:37.783] [qml] [warning] qrc:/qml/emoji/EmojiPicker.qml:298:38: QML Image: Binding loop detected for property "sourceSize.height" (qrc:/qml/emoji/EmojiPicker.qml:298, )
[2022-09-17 16:45:37.791] [qml] [warning] qrc:/qml/emoji/EmojiPicker.qml:298:38: QML Image: Binding loop detected for property "sourceSize.height" (qrc:/qml/emoji/EmojiPicker.qml:298, )
[2022-09-17 16:45:37.791] [qml] [warning] qrc:/qml/emoji/EmojiPicker.qml:298:38: QML Image: Binding loop detected for property "sourceSize.height" (qrc:/qml/emoji/EmojiPicker.qml:298, )
[2022-09-17 16:45:37.791] [qml] [warning] qrc:/qml/emoji/EmojiPicker.qml:298:38: QML Image: Binding loop detected for property "sourceSize.height" (qrc:/qml/emoji/EmojiPicker.qml:298, )
[2022-09-17 16:45:37.794] [qml] [warning] qrc:/qml/emoji/EmojiPicker.qml:298:38: QML Image: Binding loop detected for property "sourceSize.height" (qrc:/qml/emoji/EmojiPicker.qml:298, )
[2022-09-17 16:45:37.794] [qml] [warning] qrc:/qml/emoji/EmojiPicker.qml:298:38: QML Image: Binding loop detected for property "sourceSize.height" (qrc:/qml/emoji/EmojiPicker.qml:298, )
[2022-09-17 16:45:37.794] [qml] [warning] qrc:/qml/emoji/EmojiPicker.qml:298:38: QML Image: Binding loop detected for property "sourceSize.height" (qrc:/qml/emoji/EmojiPicker.qml:298, )
[2022-09-17 16:45:37.875] [qml] [warning] load glyph failed err=7 face=0x1650d779000, glyph=883 (:0, )
[2022-09-17 16:45:37.875] [qml] [warning] load glyph failed err=7 face=0x1650d779000, glyph=883 (:0, )
[2022-09-17 16:45:37.875] [qml] [warning] load glyph failed err=7 face=0x1650d779000, glyph=883 (:0, )
[2022-09-17 16:45:37.875] [qml] [warning] load glyph failed err=7 face=0x1650d779000, glyph=883 (:0, )
[2022-09-17 16:45:37.876] [qml] [warning] load glyph failed err=7 face=0x1650d779000, glyph=883 (:0, )
[2022-09-17 16:45:37.876] [qml] [warning] load glyph failed err=7 face=0x1650d779000, glyph=883 (:0, )
[2022-09-17 16:45:37.932] [ui] [info] starting nheko 0.10.1
[2022-09-17 16:45:37.956] [ui] [info] User already signed in, showing chat page
[2022-09-17 16:45:37.956] [db] [debug] setting up cache
[2022-09-17 16:45:37.961] [db] [debug] Reading 'm.cross_signing.master'
[2022-09-17 16:45:37.961] [ui] [info] Switching to chat page
[2022-09-17 16:45:38.058] [ui] [debug] Profile requested
[2022-09-17 16:45:38.258] [ui] [info] Unity service available: false
[2022-09-17 16:45:38.260] [qml] [warning] qrc:/qml/ChatPage.qml:104:17: QML RoomList: Binding loop detected for property "implicitWidth" (qrc:/qml/ChatPage.qml:104, )
[2022-09-17 16:45:38.260] [qml] [warning] qrc:/qml/ChatPage.qml:104:17: QML RoomList: Binding loop detected for property "implicitWidth" (qrc:/qml/ChatPage.qml:104, )
[2022-09-17 16:45:38.549] [db] [debug] Finished reading 'm.cross_signing.master'
[2022-09-17 16:45:38.549] [db] [error] Restoring secret 'matrix.xxxxxxxx+/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=.m.cross_signing.master' failed (7): Unknown error

Backtrace

No response

[deepbluev7]

What secrets service do you use? Is it unlocked? Does it supports the freedesktop secrets protocol or the kwallet one?

[anoduck]

@deepbluev7 Using Gnome-Keyring with the --components flag.

[deepbluev7]

Can you verify that programs like sea horse can access the keyring? It might be locked and it could be you have it misconfigured, so it can't show a prompt to unlock it.

[anoduck]

Well... I could have... but apparently not anymore.

Upon further inspection of available backends to manage secrets, I discovered the presence of numerous agents. Keychain leverages both ssh-agent and gpg-agent to manage their respective credentials, but does not facilitate an agent to manage secret storage that I know of.

Using seahorse, I was able to access and unlock the keychain, but using the terminal, when I executed gnome-keyring-daemon --unlock I was not.

Basically, I am working on setting up one all over again. Maybe Vault.

[anoduck]

@deepbluev7 Ok, I have keepassxc up and working now. I have verified that it works using both secret-tool and seahorse. I have also added authentication information contained within the configuration file as additional attributes to aid nheko in locating the desired entry. Received the same error, no change.

[deepbluev7]

How did you build Nheko? Specifically where did you get qtkeychain from? Was that built with support for gnome-secrets and stuff or just the kwallet backend?

[anoduck]

Both were installed from the OpenBSD package system, and qtkeychain is built with support for gnome-secrets.

https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/security/qtkeychain/ https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/net/nheko/

I have also integrated keepassxc with gpg-agent to manage gpg passwords.

---

I noticed that within the nheko config file the user_id possessed two '@'. Not sure if this was intentional, regardless when the extra '@' removed, it made no difference.

I am going to attempt to install kwallet next and see if that makes a difference. Gawd, that is a lot of dependencies to install, if it doesn't work, that is definitely getting removed.

[deepbluev7]

The 2 @ are because of how Qt escapes the @ in config files, so yes, that should be there.

[anoduck]

In order to install kwallet, I would have install most of the KDE system, and that is just too much.

[anoduck]

Examining the source code and discovered the error I am receiving defined at line 340, and only used in line 417 and line 483. Both lines that employ the error message involve Qkeychain, so...basically QtKeychain cannot access the secret storage.

[landryb]

Fwiw i never managed either to connect to any kind of secret service, so i disabled that part by adding a hidden setting to ~/.config/nheko/nheko.conf:

[General]
run_without_secure_secrets_service=true

not ideal, i know, but works.

cf https://marc.info/?l=openbsd-ports&m=165608153900925&w=2

[anoduck]

@landryb Thanks for the response Landry, and for everything you do for OpenBSD. You are a rock star.

[anoduck]

@deepbluev7 Confirmed the error is reproducible across OpenBSD systems. Do you know why? Would facilitating a different keyring management system such as python3 keyring make functionality feasible?

[asakura42]

Archlinux, same issue.

[asakura42]

I did

ssh-agent -k
systemctl --user restart gnome-keyring-daemon

And all works now. But using keyring is a bad choice in my opinion. I propose to add some options how to encrypt password. One of that may be GPG encrypted file or even a password stored in pass.

[deepbluev7]

We only use the secrets service API, you can use whatever application you want with that:

• https://github.com/yousefvand/secret-service
• https://github.com/mdellweg/pass_secret_service
• https://github.com/nullobsi/pass-secrets

(Some of those use pass)

[kode54]

I have a similar issue on Arch Linux. It logs in fine under a GNOME session, which uses GNOME Keyring. However, it doesn't manage to log in under a DesQ Wayland session, which defaults to starting kwalletd5. The error emitted into the console when trying to launch it there is as follows:

[2022-09-30 22:37:08.668] [ui] [info] starting nheko 0.10.2-031a129
[2022-09-30 22:37:08.675] [ui] [info] User already signed in, showing chat page
[2022-09-30 22:37:08.689] [ui] [info] Switching to chat page
[2022-09-30 22:37:08.767] [ui] [info] Unity service available: false
[2022-09-30 22:37:08.779] [db] [error] Restoring secret 'matrix.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.m.cross_signing.master' failed (7): Algorithm plain is not supported. (only dh-ietf1024-sha256-aes128-cbc-pkcs7 is supported)

[anoduck]

@deepbluev7 Landry's suggestion works. I tried it out, and no longer have any concerns with it. If it works for him, I figure, it is good enough for me.

[deepbluev7]

Landry's suggestion disables encryption for the most important data for your matrix account. If those ever get leaked, the attacker has access to all your past messages and can impersonate you. It is not a solution and using that is on your own risk. (The recent CVEs were specifically about such secrets getting leaked or replaced.)

[anoduck]

@deepbluev7 Thanks for telling me, I kinda had the feeling that it would cause encryption to turn off.

I am looking at one of the suggestions you made:

https://github.com/yousefvand/secret-service

It seems to have installed without a hitch, now I will need to discover a means to run it without systemd, and I am not sure if I want to tie it into OpenBSD's rc daemon quite yet. It might be best to use either supervisor or pm2 to manage the secretserviced backend for me. AND the setup script for this project just failed. So, I will have to work on it.

Thanks again.

[ThisNekoGuy]

Also having an issue with this over on Gentoo. The secret service is running, and Nheko contacts keepassxc to save data, but entering the password returns a "File does not exist" error where Nheko then responds by claiming the following:

(Note that keepassxc was already open and logged into a database, so it should have been able to just accept the password and commit the data provided by Nheko)

[anoduck]

@ThisNekoGuy Just out of curiosity, what version of Nheko are you running?

Also...

What desktop environment are you rocking?

[deepbluev7]

@ThisNekoGuy , did you enable the "keyring" useflag on qtkeychain?

[ThisNekoGuy]

@deepbluev7 Yes @anoduck 0.11.3 and KDE Plasma (I don't prefer KWallet, personally because its method of storing data is less portable than keepass's; sometimes I just need this on new machines)

[anoduck]

@ThisNekoGuy Well, you might not want to here this, but I was going to suggest you install gnome-keyring and run the gnome-keyring daemon. This is how I finally got Nheko to work with secure storage, as of last night about 4am.

Several of the graphical libraries (qt, gtk, etc...) don't actually pull configuration values from hardcoded configuration files, but pull variables from an intermediary process such as gnome-settings-daemon, kde-settings-daemon, etc... I imagine this scenario is similar in regards to secret-storage. There is an intermediary daemon that intercedes on behalf of the application to setup the secure storage provider, and without that intercessor the application cannot find the storage provider. It is an unsupported theory, but is what lead me to break down and install gnome-keyring.

Take it for what it is worth.

[ThisNekoGuy]

I'd rather wait for anything relevant to actually be fixed than break desktop consistency, personally

[anoduck]

You would only need the backend daemon, because the two integrate with each other. Funny enough, Kwallet is what pops up when nheko needs to access the keyring. I don't even remember installing it, and obviously there was no configuration involved, it just seamlessly did it.

I completely understand though, I used to be a big KDE fan.

[daeluk]

@anoduck Are you still on OpenBSD? Would be very grateful if you could describe what you did to get nheko working with gnome-keyring-daemon.

I currently have the following in my .xsession, but nheko keeps throwing the same error:

# start dbus for chromium and/or firefox
if [ -x /usr/local/bin/dbus-launch -a -z "${DBUS_SESSION_BUS_ADDRESS}" ]; then
        eval $(dbus-launch --sh-syntax --exit-with-x11)
fi

# start gnome-keyring-daemon e.g. for nheko
if [ -x /usr/local/bin/gnome-keyring-daemon -a -z "${GNOME_KEYRING_CONTROL}" ]; then
        eval $(gnome-keyring-daemon -d --components=secrets,pkcs11; echo "expor
t GNOME_KEYRING_CONTROL")
fi

[anoduck]

@daeluk You know it!

Interesting... because I did nothing at all. Just started it.

Literally, all I have is exec_always gnome-keyring-daemon. This is because I do not start gnome-keyring-daemon during my initialization of xenodm, I wait until after my window manager starts. My window manager being i3, thus the exec_always call. It configured itself from there. But, as previously mentioned, the utility that is being facilitated to access the daemon is oddly kwallet, which completely baffles me.

I would:

1. comment out your line invoking gnome-keyring-daemon in your xsession.
2. Restart your window/display manager without it.
3. Then attempt to invoke the keyring-daemon from your terminal. gnome-keyring-daemon
4. It should immediately background, if not ctrl-c and then add the & to background it.
5. Then start up nheko, and see if that fixes it.

If this does not work, let me know. There might be something else at play, on one of our ends.

[daeluk]

@anoduck Thanks for your response!

Hmmm interesting. Is $GNOME_KEYRING_CONTROL set on your system? Tried your suggestion (i.e. killed all running gnome-keyring-daemon s and tried invoking it and nheko from the same shell session), but it doesn't change anything.

That kwallet thing is also fun :') I don't have it installed but maybe that is what is actually working. Don't really wanna install it because of all those KDE dependencies, but maybe just to try if that works.

[anoduck]

@daeluk Yeah, the kwallet popup was not expected. I am opposed to bloated desktop environments, so it's occurrence was discomforting.

Is $GNOME_KEYRING_CONTROL set on your system?

Does not appear to be from the output of env. Where else would this be set?

---

Do you have a session of xsettingsd running?

It is time for my routine run of sysupgrade -s and sudo pkg_add -u. After reboot, I will dive into my settings for how secret storage is managed to see if this provides any further clues.

[anoduck]

@daeluk You can go ahead and write me off as an expert of anything, because over in the land of anoduckness things have continued to devolve further into mystical weirdness.

I completed my full upgrade of my system, then went to launch nheko again, except this time running gnome-keyring-daemon wasn't good enough for nheko. As it still output the same error that it could not connect to secret storage. So, I performed the unthinkable, and launched kwalletd5. This meant that I was now running two secret service daemons much to my chagrin. I went to launch nheko a second time, and viola. It accepted kwallet, as a valid secret service daemon. Seriously, WTF?

On my previously session of nheko I had not launched kwalletd, nor was it running when it accepted gnome-keyring-daemon. I was about to uninstall kwalletd seeing how I learned kicad (which was not being used), was requiring it as a dependency.

[deepbluev7]

If Nheko tries to pick kwallet, that means that you are running a KDE session: https://github.com/frankosterfeld/qtkeychain/blob/01a900bad178f69fcb0f9bc4b067c37d97762aa2/keychain_unix.cpp#L60

Alternatively it can be, that your distribution compiled qtkeychain without support for the gnome keychain, which also makes qtkeychain fall back to using kwallet.

[anoduck]

If Nheko tries to pick kwallet, that means that you are running a KDE session: https://github.com/frankosterfeld/qtkeychain/blob/01a900bad178f69fcb0f9bc4b067c37d97762aa2/keychain_unix.cpp#L60

Well, I assuredly am not running KDE-session anything if I can help it. Not that I am opposed to KDE, it is unwarranted frivolities in my current desktop environment.

Alternatively it can be, that your distribution compiled qtkeychain without support for the gnome keychain, which also makes qtkeychain fall back to using kwallet.

It is compiled with gnome-keyring support. Qt_Keychain on OpenBSD

Kwallet came from installing neochat, kicad, and ghostwriter on my system, all have now been removed.

[anoduck]

So, it appears nheko works out of the box with kwallet, but not gnome-keyring-daemon.

[deepbluev7]

Check your environment variables, what your XDG_CURRENT_DESKTOP and DESKTOP_SESSION are set to.

[anoduck]

They are unset and not apart of my current environment.

[farooqkz]

Hello. I have the same issue on a fresh Debian testing using Wayland. I have gnome-keyring-daemon running as a user service(I checked with systemctl). I also have dbus running both as a user service and a system service. But nheko is giving me the error OP posted. I also tried @landryb's suggestion but it didn't help.

Note that I'm using an old home directory(several years old!) and a new Debian install. I used to use X11 and now I switched to Wayland. If you let me know how I can reset nheko to its original state and retry, it could make a difference.

[anoduck]

@farooqkz

Resetting your state

Regardless, the configuration file for nheko is located in the $XDG_CONFIG_DIR/nheko, which is a fancy way of saying ~/.config/nheko. You can either delete the file out right rm ~/.config/nheko/nheko.conf, or copy it to a backup file cp ~/.config/nheko/nheko.conf ~/.config/nheko/nheko.conf.bak. This should reset your state.

Starting & Integrating gnome-keyring-manager

I run gnome-keyring-daemon as a user in the initialization file of my desktop environment, which is different from your current implementation. What I am trying to say is that I am unsure if it is recommended to use systemd to start gnome-keyring-daemon. If this was something done for you by installing or configuring a program, then it is fine, but if you manually enabled and started it using sudo systemctl start gnome-keyring-daemon, then it might cause issues.

The other thing I am unsure about is if you are running gnome or kde in wayland, or are you running a different wayland specific desktop environment like sway, hyprland, wayfire, etc...

[farooqkz]

Hello. Sorry for giving misinformations. I am using the flatpak version and therefore things are different. For starters, the config file was not in ~/.config/nheko but in ~/.var/app/io.github.NhekoReborn.Nheko/config.

I'm using a clean Debian installation with wayland, sway running by dbus-run-session sway with greetd. gnome-keyring-daemon is already running as I installed it using apt as a user's service(with the --user flag).

[anoduck]

@farooqkz Well, that clarifies things... I use sway on my Linux development server.

What release is your Debian installation?

Install xsettingsd and seahorse:

sudo apt update && sudo apt install xsettingsd seahorse -y && echo "exec /usr/bin/xsettingsd" >> ~/.config/sway/config
# Then
sudo reboot

Then test open seahorse to see if you can actually connect with the daemon. If you can, try running nheko from the command line and observe the output. flatpak run io.github.NhekoReborn.Nheko

The bad news is, I installed flatpak and ran it from the command line. Nheko came right up, found the gnome-keyring-daemon service, and logged in. All without a hitch. So, I am hoping by installing xsettingsd, it might resolve this situation.

[farooqkz]

@farooqkz Well, that clarifies things... I use sway on my Linux development server.

What release is your Debian installation?

Install xsettingsd and seahorse:

sudo apt update && sudo apt install xsettingsd seahorse -y && echo "exec /usr/bin/xsettingsd" >> ~/.config/sway/config
# Then
sudo reboot

Then test open seahorse to see if you can actually connect with the daemon. If you can, try running nheko from the command line and observe the output. flatpak run io.github.NhekoReborn.Nheko

The bad news is, I installed flatpak and ran it from the command line. Nheko came right up, found the gnome-keyring-daemon service, and logged in. All without a hitch. So, I am hoping by installing xsettingsd, it might resolve this situation.

For now, I've disabled the secure storage.

[anoduck]

@farooqkz Did xsettingsd not work?

[farooqkz]

@farooqkz Did xsettingsd not work?

Haven't tried yet.

[brazhh]

Same problem, Arch + hyprland i don't have gnome-keyring-manager installed but i have kwalletd6, what could be the problem?

[anoduck]

@brazhh Since previously achieving success with kwalletd and not with gnome-keyring-manager, you should be fine using it.

1. Make sure kwalletd is being started by Hyprland, this can be done by adding exec-once = /your/path/to/kwalletd &
2. Although unsure if warranted, go ahead and setup kde-polkit. ArchWiki Setup of polkit
3. Since you are comfortable having kde on your system, and have forgone installing the dependencies needed to run it, install kde-gtk-config and add xsettingsd to your hyprland config exec-once = /path/to/xsettingsd.
4. Then create your xsettings configuration file with dump_xsettings >~/.xsettingsd.
5. Then logout of everything and log back in, OR reboot your computer for a fresh start.

After this is done, give NHeko another try. What SHOULD happen, is xsettingsd should redirect the request for a secret service provider to kwalletd.

Then report back whether this worked our not.

[brazhh]

I can't use dump_xsettings >~/.xsettingsd “No current owner for _XSETTINGS_S0 selection”

I want to learn more about how it works all of this because i have never face this type of problems before, what should i need to research? I will need to have xorg installed anyway besides i use wayland?

[anoduck]

I can't use dump_xsettings >~/.xsettingsd “No current owner for _XSETTINGS_S0 selection”

I did a little digging, and believe this error message is coming from the polkit-kde-agent I mentioned previously. My reasons for doing so was primarily to mirror the same recommendations provided in the Archwiki, because it is part of the official documentation of your operating system, and secondly to ensure its availability in the instance hyprland took advantage of its features. Further research proved that the latter of these two assumptions was negative. So, in other words, "Don't shoot me, I am just the messenger."

If you want to read more on what polkit does, doesn't do, and why it can complicate simple tasks. I refer you to the documentation: Archwiki Polkit

Uninstall it and remove this line exec-once = /usr/lib/polkit-kde-authentication-agent-1 from your hyprland configuration. Then try the dump_xsettings >~/.xsettingsd again. If it does not work this time, then simply generate an empty file for now with touch ~/.xsettingsd, and xsettingsd will write your configuration options to it. The configuration syntax is in simple label/value pairs separated by a single space and one per line. Below is my xsettingsd for example:

# xsettingsd conf
# ----------------
# Configure our fonts.
Xft/Antialias 1
Xft/HintStyle "hintfull"
Xft/Hinting 1
Xft/RGBA "none"
Xft/lcdfilter "none"

I want to learn more about how it works all of this because i have never face this type of problems before.

Wayland is fairly new to most of us, except those who have invested in developing applications for it. X is still by far the most popular and dominant graphical environment, regardless of waylands growing popularity.

what should i need to research?

1. As an Arch user, the best resource is the ArchWiki, which is tops. I do not run Arch, only run Linux part-time, and use it all the time.
2. Wayland itself is closer to being a library of executables that provide instructions for interacting with graphical drivers on the kernel level. As such, it does not provide the same level of end user documentation as other programs do. Nonetheless, if you are brave, there is developmental documentation at the official site and on a private site targeted at developers. As a fair warning, it probably won't be applicable, because it is targeted at developers.
3. Thankfully, Hyprland does have some pretty good documentation

I will need to have xorg installed anyway besides i use wayland?

No. All you need is to have xwayland installed and enabled in hyprland. See Configuration of Xwayland and Xwayland troubleshooting