Hi everyone,
while working on encryption support for KArchive and the archive KIO
worker (what lets you browse “archives as folders”) I had to dive deep
into kpasswdserver.
It is completely designed around window IDs which obviously doesn’t work
on Wayland. Trying to fix it using XDG Foreign and XDG Activation is
hindered by the fact that there’s a tonne of “TODO KF6 remove” and
“deprecated, don’t use” APIs here. It also still talks to KWallet
directly instead of Qt Keychain.
Furthermore, there’s an entire infrastructure in KDEDModule for
“register window” and “unregister window” which as far as I can tell
seems completely unused outside of KIO (job tracker and that then tells
kpasswdserver). kpasswdserer uses it to expire cached credentials when
the relevant window closes.
Is that still something that’s worthwhile or should we simplify this and
track the app closing (unregister on the bus)? However, that probably
won’t work with out of process workers and is likely the reason this was
done on a per-window basis in the first place.
Do we consider kpasswdserver’s DBus API public and who is consuming it?
There’s a KPasswdServerClient class that’s used by a few (Konqueror, SMB
KDED, print-manager) but it seems nobody (of us, anyway) is talking to
kpasswdserver directly?
Can we nuke the old DBus API and make a new one that takes a _string_
window ID like the portal APIs do (and takes an options dict for future
extensions). If KPasswdServerClient were adjusted to use it, there would
be no release timing issues, would there?
Or just leave the old one untouched and make a kpasswdserverv2?
Or is this entire thing something we want to get rid of in favor of
[insert portal API/qtkeychain/whatever]?
Cheers
Kai Uwe
