OS X keychain wallets: to kwalletd or not to kwalletd?

René J.V. Bertin rjvbertin at gmail.com
Mon Sep 8 12:03:01 PDT 2014


I'm looking for a bit of feed-back here. I'm fleshing out my kwallet/OS X keychain integration a bit more, and now have a working draft of an idle timer [1] that will close a wallet after the idle time configured through the KDE `system settings`, `kcmshell4 kwalletconfig` or the kwalletmanager's preferences.
In addition, I have made some attempts to implement the normal kwalletd integration through DBus; it's this daemon that implements KDE's normal idle time close, close upon sleep, etc. Something is still missing in this protocol, but kwalletd is already started.

The feedback I'd like to have is whether or not I should pursue getting kwalletd to function. The only practical reason would probably be the idle timer that closes wallets, and it comes at the cost of having kwalletd running - which is a "foreground" application with an icon, an empty menubar, and no windows.

Myself I'd think I could do without kwalletd (or it would have to run without being noticed). What do you think?


1] Note that this is an idle timer that is independent of the one that OS X's Security framework can maintain itself. That timer would close wallets "behind KDE's" back, which works but will cause more wallet/keychain unlock requests.

More information about the macports-users mailing list