#44473: make kwallet use the OS X KeyChain as a backend, instead of kwalletd --------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.1 Resolution: | Keywords: haspatch Port: kdelibs4 | --------------------------+-------------------------------- Comment (by rjvbertin@…): 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?? -- Ticket URL: <https://trac.macports.org/ticket/44473#comment:1> MacPorts <http://www.macports.org/> Ports system for OS X

#44473: make kwallet use the OS X KeyChain as a backend, instead of kwalletd --------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.1 Resolution: | Keywords: haspatch Port: kdelibs4 | --------------------------+-------------------------------- Comment (by egall@…): Replying to [comment:1 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]) -- Ticket URL: <https://trac.macports.org/ticket/44473#comment:3> MacPorts <http://www.macports.org/> Ports system for OS X

#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

#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 cal@…): Replying to [comment:6 rjvbertin@…]:

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

Not after creating it, unfortunately. It's already present, though? -- Ticket URL: <https://trac.macports.org/ticket/44473#comment:7> MacPorts <http://www.macports.org/> Ports system for OS X

#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@…): The Review Request (for KDE 4.14.60) is here: https://git.reviewboard.kde.org/r/119838/ -- Ticket URL: <https://trac.macports.org/ticket/44473#comment:9> MacPorts <http://www.macports.org/> Ports system for OS X

#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@…): 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} -- Ticket URL: <https://trac.macports.org/ticket/44473#comment:11> MacPorts <http://www.macports.org/> Ports system for OS X