https://bugs.kde.org/show_bug.cgi?id=504709
Bug ID: 504709
Summary: KWallet: add more control over MigrateTo3rdParty
option
Classification: Frameworks and Libraries
Product: frameworks-kwallet
Version First 6.14.0
Reported In:
Platform: Other
OS: Linux
Status: REPORTED
Severity: wishlist
Priority: NOR
Component: general
Assignee: va...@kde.org
Reporter: mk.mat...@gmail.com
CC: kdelibs-b...@kde.org
Target Milestone: ---
BACKGROUND
KDE Frameworks Version 6.14 introduced an experimental option to use a 3rd
party Secret Service with KWallet, as explained in
https://notmart.org/blog/2025/04/towards-a-transition-from-kwallet-to-secret-service/
:
> Setting the following in kwalletrc:
>
> [Migration]
> MigrateTo3rdParty=true
> [KSecretD]
> Enabled=false
>
> With this, the old KWallet backend (now a service called ksecretd)
> won't be started anymore, and instead any Secret Service provider
> that is running or has been configured to be DBus-activatable will
> be used. The first time this happens, a data migration procedure
> will be executed, writing the data in KWallet into the new service
PROBLEM
This leaves the possibility that sensitive data may be unintentionally exported
to the wrong Secret Service provider.
For example, KeePassXC will refuse to enable its own Secret Service while the
org.freedesktop.secrets DBus address is occupied (the relevant setting is
disabled in KeePassXC). To migrate the data from KWallet to KeePassXC, ether a
very clunky process is necessary, going back and forth between KWallet and
KeePassXC in multiple steps (see for example
https://github.com/keepassxreboot/keepassxc/issues/3679#issuecomment-2902735982
); or kwalletrc must be modified as above before KeePassXC is ready to take
over.
If the user has other Secret Service providers installed, and has not properly
disabled them - for example Gnome Keyring, which some users have installed
without their knowledge - then, while the KeePassXC is being prepared, a
migration may accidentally occur into such other Secret Service provider.
Moreover, the wallet will then be marked as "migrated", and the desired
migration to KeePassXC will not occur.
PROPOSED SOLUTION
- Allow the MigrateTo3rdParty option to specify the executable path of the
intended migration target, such as "/usr/bin/keepassxc". When a migration is
considered, check the published binary path of the org.freedesktop.secrets bus
and compare to the setting value. Migrate only if the setting value matches the
owner binary path, or is "true".
- Alternatively or in addition, ask for user confirmation before actually
executing the migration.
--
You are receiving this mail because:
You are watching all bug changes.
