make kwallet use the OS X KeyChain as a backend, instead of kwalletd

[RJVB (René Bertin)]

It turns out kdelibs4's code and build system already provide the necessary elements to use OS X's KeyChain as a backend for the KDE Wallet, rather than kwalletd. As described on the mailing list this is not (yet) a perfect integration in the sense that it currently uses KDE-specific instead of reusable (from OS X apps) entries, but it's better than a completely separate password storage system.

The snippet to add to the kdelibs4 portfile is below. I'm not attaching a diff to this ticket as my kdelibs4 portfile currently contains other additional variants under testing (but I could generate one if really required).

variant osxkeychain description {kwallet uses the OSX KeyChain} {}
if { [variant_isset osxkeychain] } {
     configure.args-append -DMAC_USE_OSXKEYCHAIN:BOOL=ON
}

[RJVB (René Bertin)]

Observations & questions I posted on the ML:

• KeyChain entries are all called kdewallet and of type "application password". Is this due to the way the kwallet system handles credentials, or would it be possible to tune this?

• some entries have an empty password, for instance one that appears to be related to my Google Contacts akonadi resource, which (but) has my email address in the account field instead of the resource ID (akonadi_googlecontacts_resource_1) as is the case with my imap accounts.

Interestingly, that Google Contacts resource is the only one which no longer works correctly with the OSX KeyChain backend. It fails to connect when the agent starts, claiming that "the configured account does not exist" and obliging me to reconfigure it after each restart. (After that, it just works.)

• The same applies to the internet site password I tried. The corresponding entry is called (and "where") kdewallet of type "application password", has the right account (the URL), but no password. I'm a bit stymied how it works ... I checked if the pw field did not by chance contain an invisible, binary-encoded pw by setting it to an empty string, and still could connect. Is it possible that kwallet or the OSX KeyChain somehow ... keychains the request and finds the password in one of the entries stored by a native (OS X) browser??

[RJVB (René Bertin)]

The snippet to add to the kdelibs4 portfile is below.

variant osxkeychain description {kwallet uses the OSX KeyChain} {}
if { [variant_isset osxkeychain] } {
     configure.args-append -DMAC_USE_OSXKEYCHAIN:BOOL=ON
}

Actually, it might be better to reverse the logic to make the use of the KeyCHain backend the default?!

[cooljeanius (Eric Gallager)]

Replying to rjvbertin@…:

Observations & questions I posted on the ML

(the mailing list in question here was macports-users, for reference, and the post in question was: ​https://lists.macosforge.org/pipermail/macports-users/2014-July/036006.html)

[RJVB (René Bertin)]

I have rewritten the OSX Keychain backend almost completely, in order to support as much of the kwallet functionality as possible when storing the data (wallet entries) in OS X keychains (keychain items):

• support for multiple "wallets" (creating, reading, writing, deleting)
• emulation of the kwallet folder feature
• OS X Keychain utility can display and edit part of the KDE information. The actual information in KDE Wallet::Map entries cannot be read (QMap stored as BASE64 and displayed as such). A comment explains to use KDE's kwalletmanager to read these.
• The kwallet subsystem stores the wallet entry types as keychain item kSecItemAttr attributes. It (including kwalletmanager) won't read items that lack this information and thus items created by/stored for OS X applications show up as unknown entries in the manager. They can be deleted, however.
• modified and extended kdeui/tests/kwallettest.cpp for more exhaustive testing (also with the regular kwallet backend).

There is thus only a limited form of integration, due to differences in how information is stored and provided. I tried to map "generic password items" from OS X to KDE Wallet:Password entries, but for now I lack sufficiently exhaustive documentation on these entries are used under KDE. The API to read/write them only supports key (account) / value (password) pairs, so the "where/what-for" information is missing. A quick look at the wallets on my Linux system suggested that applications use their own individual approaches, so I decided to leave the implementation as described above. Similarly, KDE applications that store credentials as QMaps cannot be stored as completely native OS X keychain items. Those QMaps contain key/value pairs for both user ID and password that store the credential names ("username", "ID", "email"; "password", "passphrase", "pincode", etc) as well as their values. There's no guaranteed unambiguous way to reinterpret those QMaps as standard credential value pairs as QMaps are sorted alphanumerically by key (so the username/ID pair isn't always the 1st) and in addition I have seen cases where the map contains more than 2 key/value pairs.

patch files that will have to be appended in the osxkeychain variant proposed in this ticket:

• use-osx-keychain.patch contains the modifications to kdeui/CMakeLists.txt and kdeui/util/kwallet_mac.cpp as well as the complete source for 2 new files, kdeui/util/qosxkeychain.{cpp,h}
• kwallettest.patch contains the modifications to the unit test tool.

These patches will work with KDE 4.13 too (at least with the source; double-check the CMake files!!); researching how to get them into upstream will be my next project.

See also ticket #44655 (​https://trac.macports.org/ticket/44655) for a companion correction/enhancement to the AuthServicesBackend that allows applications to gain privileges.

[RJVB (René Bertin)]

Can't I add the haspatch keyword to this ticket myself?

[neverpanic (Clemens Lang)]

Replying to rjvbertin@…:

Can't I add the haspatch keyword to this ticket myself?

Not after creating it, unfortunately. It's already present, though?

[RJVB (René Bertin)]

So much for me ... I thought I hadn't added it because I didn't attach any patchfiles initially. There was a "patch" in the report body though, which could explain things.

[RJVB (René Bertin)]

The Review Request (for KDE 4.14.60) is here: ​https://git.reviewboard.kde.org/r/119838/

[mkae (Marko Käning)]

I'll have a look into these in a week or so.

[RJVB (René Bertin)]

corrected 2 potential CFRelease of a null pointer cases, made Wallet::writeEntry(QString&,QString&) generate Wallet::Stream entries and (yeehaa) added license blurbs to qosxkeychain.{cpp,h}

[NicosPavlov]

Committed in r126340 along with 4.13.3 update.