[MacPorts] #44473: make kwallet use the OS X KeyChain as a backend, instead of kwalletd

[MacPorts]

#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