#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