Dear Maintainer,

    * What led up to the situation?

Upgrading my testing system. Doing so upgraded kwallet6 from
6.13.0-1 to 6.18.0-2

    * What was the outcome of this action?

After the upgrade, I rebooted my system. When logging in again, kwallet
fails and blocks all other programs that stored passwords in the wallet:
   - Wireless Network fail to connect, as they can not access their
     stored passwords anymore (No password entry dialog pops up)
     (Configuring the connection for all users allowed me to enter a
     password and connect.)
   - KMail can't access the account passwords
     - "normal" IMAP accounts stay offline
     - "XOAUTH2 accounts open the webbrowser but afterwards fails to
       store the token
   - Nextcloud stays offline and does not ask for a password.
   - KWalletManager shows "An error occured when connecting to the
     KWaller service: Did not receive a reply. Possible causes [...]"

    * What outcome did you expect instead?
The wallet is still accessible after the upgrade ;-)


    * Additional Info:

* I originally created this message yesterday, but due to a broken
mail-config (unrelated), reportbug failed to send this message, so I
manually send it now.
* It seems both /usr/bin/kwalletd6 and /usr/bin/ksecretd are running.
* This was the second time I tried upgrading kwallet. My first try was
on 2025-10-15 - with the same result.
I then assumed there was some missing migration, downgraded to 6.13.0-1
(sudo aptitude install kwallet6=6.13.0-1 libkf6wallet-data=6.13.0-1
libkf6walletbackend6=6.13.0-1 libkf6wallet6=6.13.0-1 kio6=6.13.0-7+b1)
and held kwallet6.
* Today I tried upgrading again with the same result, so I'll be
downgrading again once this bug-report has been submitted.
* libqca-qt6-plugins is installed on my system

After quiet some more upgrade- and downgrade dance, things seem to work
mostly correctly now. What I did:

After another upgrade, that ended up with a broken system again, I tried
removing my existing kwallet (mv .local/share/kwalletd/ kwallet_orig). I
then created a new gpg-protected wallet.

This helped partially (I could add a password for my Wireless network or
for Nextcloud again) but not fully. KMail was still unusable failing to
even open the settings for my IMAP account.

So I removed the new wallet, moved the old back into place and
downgraded again to 6.13.0-1.

After rebooting into the old system KDE asked me to create a new default
wallet again. Again I selected a gpg-protected wallet. Now I had to
reregister all passwords but this worked. And even KMail now managed to
save passwords into the new wallet. In KWalletManager I found both the
old and the new wallet and could open both of them.

Now I just upgraded kwallet again and after another reboot, everything
seems to be happy using the new wallet. In KWalletManager I still see
both my wallets.

HOWEVER: Trying to open the old wallet in KWalletManger crashes the
WalletManager and seems to block KMail again. Logging out and back in
does not help, only rebooting does.


Given this observations, it seems that there are still quiet some rough
edges here.

1. There should be a path to migrate an existing wallet automatically.
2. The upgrade should make sure a new wallet exists before it removes
the ability to open old wallets.
3. Once the old wallets can not be opened anymore, no tool should try to
do so (or at least error out without crashing the whole wallet-system)

Hope this information helps smoothing out the upgrade process for future
users (and the forky release)

Hi fellow user,
I've just finished upgrading. Same conf, same packages versions, and I can *partially* confirm.
There was a strange "delay" after the first reboot: the system asked for my Wi-Fi passwords. Having read your report via the integrated apt util, I did NOT insert the password: instead, I opened up the wallet via GUI and it opened fine. As soon as I did this, the Wi-Fi connected on its own.
Will reboot ASAP and double check, but I wanted to write this report while my memory is still fresh.

Hi,
just to confirm it's still fine after multiple reboots. I'm available for feedbacks if needed.
Have a nice day

Hey,

I cannot reproduce your issue for me everything works fine for me on unstable.

With 6.14 kwallet replaces its interface to use ksecretd, that actually uses
the defined secretservice interface, that also other secret managers are using
(oo7, keepassxc).

So properly you are not asking kwallet anymore but an other service.

Can you check what service answers the dbus interface in you current versions?

I use normally d-feet for this.

* use the "sessionbus" tab
* look at "org.freedesktop.secrets"
 ( in your pre 6.14 version it should not exist!)
 (after 6.14 proviced by ksecretd)
* look at "org.kde.kwalletd")
(needs to be run by kwallet6 for every kwallet version :)

Btw. are you actually using a proper testing or unstable system?  990 for
stable-security is properly breaking things as 990 will downgrade packages
from testing/unstable so you have a unsupported mix of stable, testing and
unstable.

Regards,

hefee

Thanks for getting back.

My system has been running reliably since my 2nd message above:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1119238#10

As written in that message, I assume this was primarily a migration
problem - and as such I can not investigate this easily anymore.
Unfortunately d-feet has been removed from Debian last summer:
   tracker.debian.org/pkg/d-feet

However running dbus-monitor and opening KWalletManager prints lots of
output like these:

method call time=1776152806.428781 sender=:1.3707 ->
destination=org.kde.kwalletd6 serial=61 path=/modules/kwalletd6;
interface=org.kde.KWallet; member=entryList
   [...]
method call time=1776152806.429115 sender=:1.58 -> destination=:1.49
serial=2947 path=/org/freedesktop/secrets/collection/Default_20keyring;
interface=org.freedesktop.Secret.Collection; member=SearchItems
   [...]

So here everything seems reasonable.
Not a pure testing system, but I don't think this was relevant here.
stable-security to get security updates as long as I do not have a more
recent version installed already. (Mainly affects my browsers and has
been working well for the last years.)

best wishes
Nicola

Hi

I had some weird issues after apt dist-upgrade and reboot:
  - got a lot of "Service crash" notifications
  - after restart of kwallet, a lots of secrets are missing. I could see
secret keys but not their values.
  - akonadi imap agent connected to google try to renew google token

After reading this bug report (thanks for the help), I've logged out and in.
Delay between login and desktop was quite long, so I suppose the migration was
resumed.

Then:
  - kwallet manager secrets were back
  - most imap agents were back
  - one imag agent always crashed on restart

I had to remove ~/.config/akonadi/
agent_config_akonadi_imap_resource_2_changes.dat to fix the imap agent crash.

Now everything look back on track.

Hope this helps

Hi,

thanks for mesage. Actually that helped me to understand what this bug is
really about ;)
It is about the migration process from KWallet to KSecretd that is happening
in background and the user don't get feedback and additionally while the
migration process is happening the application that try to use KWallet/
KSecretd are failing...

That is a actually not a nice user experience. We need bring this issue to
upstream KDE. Did you already search in bugs.kde.org, if this problem is
already reported? If not can you report this in KDE?

Regards,

hefee

Moin,

Oh I've missed this message. When started reading this issue, I didn't understood, that you are taking
about the the migration process of KWallet -> KSecretd. Where the feedback is missing for the user and
actually unclear if it is happening and things seem broken...

That is a actually not very nice - you are right. We need bring this issue to  upstream KDE this information,
as they need to fix it. Did you already search in bugs.kde.org, if this problem is already reported?  If not can you report this in KDE?


Regards,

hefee

close to our problem except it's about framework 6.25 whereas I upgraded from
6.23.0-1 to 6.23.0-2.

Other updates related to kwallet are:
- kwallet6:amd64 (6.23.0-1, 6.23.0-2),
- libpam-kwallet-common:amd64 (6.5.4-1, 6.6.3-2),
- libpam-kwallet5:amd64 (6.5.4-1, 6.6.3-2),

The first one is a minor update.

The libpam-kwallet is a mistery. Upstream [1] versions (6.5.90, 6.6.80...) do
not match Debian package version.

For what it's worth, I've attached the list of upgrades done before the
problem I described showed up.

Currently, I don't really know what to report.

All the best

[1] https://invent.kde.org/plasma/kwallet-pam

Hey,

thanks for checking the upstream bugs.  But this upstream bug actually is
actually an issue inside OpenSuse and has nothing to do with the migration
process. At least the linked OpenSuse bug reads like this.

It is impossible that the upgrade from  6.23.0-1 to 6.23.0-2 triggered this,
because the changes in this version bump are only some packaging cleanup and
no upstream changes. But this maybe triggered the previous failed migration
again...

kwallet-pam is for sure not the reason, this is just the pam integration of
kwallet. So this can be ignored.

what you mean by that? the .90 and .80 are release candidated/beta releases,
that are not packaged inside Debian. But the tag shipped in Debian 6.6.3
exists in the repo, so everything is fine.

without kwallet5 you can remove this one.

I think what is happening:

kwallet 6.14 added the migration to ksecretd, this migration failed  at that
stage, fallback to kwallet. Now plasma realized that and started the migration
again. This migration take quite some time. While apps that want to get
credentials time-out and trigger the "Service crash" notifications...
After the migration finished everything get back on track.

So the bug is actually about this time-out and not informing the user, that
the migration is happening and they should be pageant.

Regards,

hefee

Dear all

I just tested the upgrade in a VM. Of course the VM had only very few
passwords saved and did not need one to connect to the network. So it
did not try to access the wallet immediately after login.

Still things seemed to work reasonably:

- During the upgrade listchanges displayed the new warning from Sandro
pointing to this bug.

- After the upgrade, I tried to use a saved FTP connection and the was
prompted for the password. I cancelled.

- I then opened KWalletManager, it showed one wallet and after I could
open the wallet. (by now some time had passed)

- I retried the FTP connection and this time that worked without a
password prompt.


So from my point of view this is still not perfect, but not a grave bug
anymore.

best
Nicola

control: severity -1 normal

Le mercredi 29 avril 2026, 11:52:27 heure d’été d’Europe centrale Nicola Chiapolini a écrit :

[…]

Thanks for the feedback.

Updating severity accordingly.


Happy hacking,
--
Aurélien

kwalletmanager:amd64 (4:25.04.2-1, 4:26.04.0-1),

Note that there was a lot of other upgraded packages. The whole list is
attached.

I again got empty secrets in kwallet.

I've worked around this issue by logging out and back in.

HTH