Kwallet now asks for password on login (since latest update)

[renkforce]

Already mentioned here by Yochanan, I also can confirm this new issue on manjaro stable with latest kwallet 6.14.0-2.

Before the latest update, kwallet started alongside the other kde services and silently unlocked using my user account password. This worked for years across many machines without any issue.

Now kwallet asks for my password on login, which never was the case before.

Edit: @Yochanan: It also dumped core, this is definitely related to recent updates from yesterday afternoon. The kwallet version distributed 2025-05-14 with all the other latest stable packages didn’t have this specific issue.

[Nachlese]

As I was reading this, I had just seen this recent post:

CONFIG_EXT4_FS_SECURITY not set in kernel config of Manjaro-arm64 `linux` package

and thought that these two could be connected.
It is only speculation!
May be worth looking into it.

[renkforce]

Thanks for your reply, but it seems unrelated as I don’t use ext4 on any of the machines affected by this kwallet issue.

[philm]

Please do a downgrade to the 6.13.0 version of kwallet via sudo pacman -Syuu. The package should have never been forwarded to stable branch as that was not affected at all. The regression was introduced with kde frameworks 6.14 series.

[renkforce]

Thanks, downgrading to kwallet 6.13.0-1 resolved this issue

[renkforce]

Now vivaldi seems to be unable to open the profile and suggest to “continue with data loss” and Signal messenger is unable to open at all. Both worked before upgrading to 6.14 yesterday. Downgrading to 6.13 restored kwallet itself but introduced those new issues.

[rethus]

@philm

sudo pacman -Syuu

Same here!
Additional to that, KDE forget WLAN-Password after each reboot and Nextcloud-Sync client isn’t able to login anymore.

Strange issues I’ve never had before after Manjaro-Upgrades. What’s happen here?

[medmedin]

I’m on unstable branch with KDE Frameworks 6.14.0 and KWallet never asked for my saved wifi passwords.

It seems Manjaro stable is pushing something wrong for stable users or their repos are not well synchronized.

[Sam_Fisher]

The latest update to kwallet introduces something called “ksecretd”. And it wasn’t well written i assume so it is causing the problems we are having. The bug reports you need to follow are:

https://bugs.kde.org/show_bug.cgi?id=504251
https://bugs.kde.org/show_bug.cgi?id=502808

It is interesting that one of the replies claim that the problem can be solved by just one line of code, but we are waiting for the devs to pick it up i guess. I assume it is not a widespread bug, only affecting certain architectures.

[emaus]

Almost same problem also wifi key was lost after every reboot. Happen after last kwallet update.
This topic helped me. Two reboots and doesnt asked it anymore. Dont know is it right solution though.

[doctorx]

I went in and changed the wallet password to nothing and that seemed to fix it for me. Everything seems to be working. Now i wonder if i should change it back to my user password and downgrade or leave it as is?

[rethus]

@emaus thanx for sharing this.
Even if it’s not a nice solution (to have an kwallet unsecured activated in the system) it might be a temporary workaround.

Would love to be able to fully deactivate kwallet, as I prefer to use KeepassXC, but deactivate KWallet in the settings also have no effect.

[scotty65]

@rethus

Would love to be able to fully deactivate kwallet, as I prefer to use KeepassXC, but deactivate KWallet in the settings also have no effect.

You might be interested in this change, which was mentioned in This Week in Plasma: many many things - KDE Blogs a month ago & has commenced rolling out in Frameworks 14:

Frameworks 6.14

KWallet is now just a wrapper around the cross-desktop “Secret Service” system, plus a thin compatibility layer for apps that haven’t migrated to use Secret Service directly. Read more about this here! (Marco Martin, link)

The linked article: Towards a transition from KWallet to Secret Service | Mart

KDE Frameworks (kf6) 6.14 has reached Unstable & Testing branches. Stable branch is currently on kf6 v6.13:

Output of: mbn info kauth -q | grep -Ev 'Name|Repository|Packager'

mbn info kauth -q | grep -Ev 'Name|Repository|Packager'
Branch         : archlinux
Version        : 6.14.0-1
Build Date     : Sat 10 May 2025 18:14:19 
Branch         : unstable
Version        : 6.14.0-1
Build Date     : Sat 10 May 2025 18:14:19 
Branch         : testing
Version        : 6.14.0-1
Build Date     : Sat 10 May 2025 18:14:19 
Branch         : stable
Version        : 6.13.0-1
Build Date     : Sun 20 Apr 2025 17:22:54 

_{mbn can be found in the manjaro-check-repos package}

[Sam_Fisher]

ksecretd still crashes for me upon every boot (version 6.14.1-1). Manjaro ARM.

The provided coredumpctl output details a crash of the ksecretd process (PID 978) from a previous boot (3e8a1d6df9b749bc8711de6c1f5f0332) on May 19, 2025, at 10:00:10 +03, caused by a segmentation fault (SIGSEGV) in the Qt Cryptographic Architecture (QCA) library (libqca-qt6.so.2). This aligns with prior discussions about ksecretd instability and its impact on kwalletd6, which logged D-Bus errors due to ksecretd issues. As of 10:38 AM +03, May 19, 2025, your recent systemctl --user status output confirmed both ksecretd (PID 967) and kwalletd6 (PID 956) are running in the current boot (277cc2511996419fa1dd391007c22378). Below, I’ll analyze the crash, its implications for the current session, and provide steps to prevent recurrence, focusing on ksecretd and kwalletd6.

Analysis of ksecretd Crash (PID 978):

1. Crash Details:

• Process: ksecretd (PID 978, user: turker, UID/GID: 1000)
• Signal: SIGSEGV (segmentation fault)
• Timestamp: May 19, 2025, 10:00:10 +03 (38 minutes ago, prior boot)
• Executable: /usr/bin/ksecretd
• Unit: dbus-:1.1-org.kde.secretservicecompat@0.service
• Stack Trace:

text

Copy

#0 0x0000ffff2bea70f8 n/a (libc.so.6 + 0x870f8) #1 0x0000ffff2be56f9c raise (libc.so.6 + 0x36f9c) #2 0x0000ffff2e184d24 _ZN6KCrash19defaultCrashHandlerEi (libKF6Crash.so.6 + 0x4d24) #3 0x0000ffff2e708828 n/a (ld-linux-aarch64.so.1 + 0x38828) #4 0x0000ffff2e708828 n/a (ld-linux-aarch64.so.1 + 0x38828) #5 0x0000ffff2e067e78 _ZN3QCA12MemoryRegionD1Ev (libqca-qt6.so.2 + 0x77e78) #6 0x0000ffff2beb6fac n/a (libc.so.6 + 0x96fac) #7 0x0000ffffc5a86190 n/a (n/a + 0x0)

• Key Frame: The crash occurred in QCA::MemoryRegion::~MemoryRegion() (frame #5) from libqca-qt6.so.2, indicating a memory corruption or invalid pointer access during the destruction of a cryptographic memory region.
• Architecture: AArch64 (ARM64), consistent with your system.

2. Cause:

• The segmentation fault in QCA::MemoryRegion::~MemoryRegion() suggests:
  • A bug in the QCA library (libqca-qt6.so.2), possibly specific to AArch64.
  • Memory corruption triggered by ksecretd handling a Secret Service request, likely from an app like Flatpak Chromium.
  • Possible interaction with corrupted wallet data from kwalletd6.
• The crash was caught by KDE’s crash handler (KCrash::defaultCrashHandler), which raised the SIGSEGV.

3. Relation to kwalletd6:

• kwalletd6 (PID 956, current boot) relies on ksecretd for Secret Service API compatibility. The crash of ksecretd (PID 978) in the prior boot likely caused kwalletd6’s D-Bus errors, such as:
  • g_dbus_proxy_get_object_path: assertion ‘G_IS_DBUS_PROXY (proxy)’ failed
  • qt.dbus.integration: QDBusConnection: name ‘org.kde.secretservicecompat’ had owner ‘’ but we thought it was ‘:1.37’
• These errors appeared in the current boot (10:02:20) despite ksecretd (PID 967) running, indicating ongoing D-Bus synchronization issues.
• kwalletd6’s log of Secret Service availability changed: Available suggests it recovered, but non-KDE apps may still be affected.

[TheFreed]

I ran in to this today, or probably a few days ago, network manager has been acting up with password at login.
Sudo pacman -Syuu doesn’t do anything, has the package been pushed to the branch again?

Edit: Installed manjaro-dowgrade to downgrade but the problem persist even on 6.13.0

[renkforce]

Now that I’ve updated several machines (all working flawlessly before the recent patchset), they now behave differently with no obvious reason.

After initial crashing and after several restarts, most of the machines have a fully functional kwallet now. All secrets are in place and accessible.

On some other machines, simply trying to enumerate the wallet entries fails and waits forever:

kwallet-query -v kdewallet -l

timer event
standby opening wallet  "kdewallet"

In the second scenario, KWalletManager has the same issue and cannot connect to the service. The KWallet kcm however is still working. Configuration changes can be applied and permissions can be adjusted.

The system log currently shows no crashes or any other errors.

[kpanic]

@philm

downgrade

I zapped ~/.local/share/kwalletd and ~/.config/kwalletrc

Then I downgraded (via manjaro-downgrade) to 6.14.0-2 and it seems to work fine for me after one logout/login

[TheFreed]

6.14.0-2 is current version so not a downgrade but reinstall.
I did start to suspect some user files since downgrade didn’t help, maybe just delete those files and reboot could have worked (if they are recreated).

I solved it with this

[Stable Update] 2025-05-19 - Firefox, Thunderbird, KDE Gear, KDE Frameworks

I initially voted no issues but soon realized I had problems with kwallet which I can’t solve. Now thinking of timeshift back to a pre 2025-05-14 but not sure that will help since a downgrade kwallet 6-13 did not help. EDIT: @Aragorn @Yochanan I just solved it, for me and probably others with the same problem of kwallet not starting https://wiki.archlinux.org/title/KDE_Wallet#Automatic_D-Bus_activation Most applications use org.freedesktop.secrets.service D-Bus service. KWallet does not pro…

EDIT: For someone else searching for a solution, removing ~/.local/share/kwalletd will remove your passwords so if you use kwallet you should probably not go that route