https://bugs.kde.org/show_bug.cgi?id=524522
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #13 from [email protected] --- I can reproduce this on Arch Linux as well, but my reproduction pattern is somewhat different from the original report. Environment: Arch Linux KDE Plasma / Wayland kwallet 6.29.0-1 qca-qt6 2.3.10-8 OpenSSL 3.6.3-1 Chromium 151.0.7922.173-1 I have observed the ksecretd crash twice so far. Both crashes have the same stack trace: EVP_CIPHER_CTX_set_key_length() -> libqca-ossl.so -> QCA::Cipher::setup() -> QCA::Cipher::Cipher() -> ksecretd The more detailed backtrace also matches the one in this bug: KWalletFreedesktopSessionAlgorithmDhAes::encrypt() -> KWalletFreedesktopSession::encrypt() -> KWalletFreedesktopService::ensecret() -> KWalletFreedesktopItem::getSecret() -> KWalletFreedesktopService::GetSecrets(). Both core dumps were generated by: /usr/bin/ksecretd --pam-login 8 9 I also noticed that the issue is intermittent on my system. In some cases, starting Chromium is followed immediately by a KWallet password prompt, and ksecretd may crash around that time. However, not every Chromium start triggers the crash. There is also an important difference from the original report: one of my crashes happened before Chromium was started. My journal showed: 19:45:17 systemd: Started Unlock kwallet from pam credentials. 19:45:19 ksecretd: ... 19:46:18 ksecretd dumped core 19:47:39 systemd: Started Chromium So Chromium is not necessarily required for the crash itself. This makes me suspect that Chromium is sometimes just the first client that performs the relevant Secret Service operation after the PAM-launched ksecretd is running. When the crash happens, the subsequent KWallet password prompt is expected because the original ksecretd --pam-login process has terminated. The two crashes I captured were: 2026-08-23 15:37:37 +05 PID 1085 ksecretd --pam-login 8 9 2026-08-25 00:40:47 +05 PID 1056 ksecretd --pam-login 8 9 Both crash in exactly the same place in libcrypto.so.3 / libqca-ossl.so. This seems consistent with the investigation in this report concerning the OpenSSL default provider and QCA 2.3.10. I am attaching/providing my full coredumpctl info ksecretd output and journal excerpt in case they are useful for correlating the crash with the Secret Service request. One question that may be useful for debugging: could the relevant Secret Service/D-Bus request made immediately before the crash be logged or otherwise traced, so that we can identify which client/request (e.g. Chromium) triggers KWalletFreedesktopService::GetSecrets()? -- You are receiving this mail because: You are watching all bug changes.
