#44473: make kwallet use the OS X KeyChain as a backend, instead of kwalletd --------------------------+---------------------- Reporter: rjvbertin@… | Owner: nicos@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: kdelibs4 | --------------------------+---------------------- Comment (by rjvbertin@…): 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 ''QMap''s 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} - These patches will work with KDE 4.13 too; 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. -- Ticket URL: <https://trac.macports.org/ticket/44473#comment:5> MacPorts <http://www.macports.org/> Ports system for OS X