[KDE/Mac] Review Request 119838: [OSX] backend improvements for kwallet/Keychain integration and AuthServices

Thu Sep 18 22:06:03 UTC 2014

> On Sept. 4, 2014, 3:23 a.m., René J.V. Bertin wrote:
> > I've been test-driving this configuration for a few days, using kmail as my email client, and that does raise a question.
> > 
> > With standard kwallets, who's responsible for closing them (after a given time, when the last client connects, etc)?
> > These features appear not to work, which I guess might be related to the fact that kwalletd doesn't get build when using OSX Keychain integration? OS X's own timed closing feature works ... too good. That is, the keychain is closed even if I poll an imap account every 5min while the keychain is set to be closed after 10min in inactivity.
> > 
> > I'm unfamiliar with how kmail/akonadi_imap_resource cache credentials, but I've seen cases where the OS closed the keychain holding the wallet and the clients continued to function as if it were open.
> 
> Ian Wadham wrote:
>     Have you seen http://docs.kde.org/stable/en/kdeutils/kwalletmanager/index.html or
>     http://docs.kde.org/stable/en/kdeutils/kwalletmanager/kwallet-kcontrol-module.html?
>     You should also be able to find doco for kmail/akonadi on http://docs.kde.org/.
>     Maybe there is some API doco on kwallet at http://api.kde.org/.
> 
> Albert Astals Cid wrote:
>     wallets are closed from kwalletd.cpp, see the _closeIdle and _idleTime variables. If you're using your own wallets and not kwalletd i guess you need to do some OSX stuff yourself?
> 
> René J.V. Bertin wrote:
>     Yes, I've been looking at kwalletd's source, and more or less decided I wasn't very interested in changing them. I did get the integration with kwalletd up and running in kwallet_mac.cpp by copying over the relevant code from kwallet.cpp (or so I think), but it's as if there is no communication through the dBus.
>     
>     From what I understand, wallet management is actually asynchronous, at least as far as closing is concerned. That's not how my current version of kwallet_mac works. Is there anything (policy, API considerations, ...) against implementing a timer in kwallet_mac.cpp so that at least the idle timeout feature works from inside KDE?
>     
>     Also, while kwalletmanager can open and close wallets just fine, the wallet's icons don't change state, at least not when closing the wallet. Does it wait for a (dBus) signal for that, and how can I check if at least my code does the required things to emit that signal? (Regardless of whether dBus functions correctly, I mean)
> 
> René J.V. Bertin wrote:
>     Re: icon state: I just noticed that the same thing happens on Linux, so apparently "it's not me" :)
> 
> Albert Astals Cid wrote:
>     I'm confused, why was this reopened? The patch has been commited, no?

Yes. I'm not sure who closed it, nor who did the commit, but when I reopened this I hadn't noticed it had been committed. Anyway, I'll close it again, because I opened another RR for the follow-up on this project (https://git.reviewboard.kde.org/r/120202/).

- René J.V.

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119838/#review65783
-----------------------------------------------------------

On Sept. 2, 2014, 11:38 p.m., René J.V. Bertin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119838/
> -----------------------------------------------------------
> 
> (Updated Sept. 2, 2014, 11:38 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and Valentin Rusu.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> -------
> 
> The submitted improvements to kwallet consist of a number of changes to existing files, as well as 2 new files that contain the actual interface to OS X's SecKeychain API. The proposed improvement to AuthServices consist in moving the authentication from the helper (back) to the client.
> 
> With these modifications, KDE wallets are stored in the same location as native OS X keychains, and both can be managed (up to a certain extent) in the OS X Keychain utility as well as the kwalletmanager. The modifications to the AuthServices make it possible to edit the kwallet configuration in the associated control module. And last but not least, password prompts no longer get posted somewhere in the background.
> 
> I'm bundling both in a single RR because even if they're independent they are strongly related.
> 
> 
> A more detailed discussion can be found on trac.macports.org:
> 
> https://trac.macports.org/ticket/44473
> https://trac.macports.org/ticket/44655
> 
> 
> Diffs
> -----
> 
>   cmake/modules/KDE4Macros.cmake bde7cfe 
>   kdecore/auth/backends/mac/AuthServicesBackend.cpp 56ef114 
>   kdecore/auth/kauthaction.cpp 8fbd61c 
>   kdeui/CMakeLists.txt b439e04 
>   kdeui/tests/CMakeLists.txt f661b91 
>   kdeui/tests/kwallettest.cpp 245959b 
>   kdeui/util/kwallet_mac.cpp a6bf4c0 
>   kdeui/util/qosxkeychain.h PRE-CREATION 
>   kdeui/util/qosxkeychain.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/119838/diff/
> 
> 
> Testing
> -------
> 
> Development and testing was done under MacPorts on OS X 10.6.8 running KDE 4.12.5, which is part of my production environment. Apart from regular use, I expanded/improved kdeui/tests/kwallettest.cpp and verified that XML exports of my Linux kwallets imported cleanly under OS X.
> I also copied modified kwallettest file into the 4.13.3 kdelibs tree on my Kubuntu 14.04 system and verified that it builds and runs without errors.
> 
> All patches from my 4.12.5 tree (and published in the trac tickets above) applied cleanly to the 4.13 and 4.14.60 (git/master as of earlier today) trees, the resulting code builds and kwallettest executes without errors.
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20140918/94c6d71b/attachment.html>