[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-mac
Subject:    Re: [KDE/Mac] kwallet and the OS X keychain
From:       "René_J.V._Bertin" <rjvbertin () gmail ! com>
Date:       2014-07-29 10:06:08
Message-ID: 642D83E6-4C7D-49C1-A82E-9C1463005056 () gmail ! com
[Download RAW message or body]

Morning!

On Jul 29, 2014, at 10:01, Frank Osterfeld wrote:

> 
> On 28 Jul 2014, at 23:30, René J.V. Bertin <rjvbertin@gmail.com> wrote:
> > 
> > I just stumbled across a Cmake variable/flag, MAC_USE_OSXKEYCHAIN :
> > 
> > > option(MAC_USE_OSXKEYCHAIN "On OS X, use the keychain as backend for kwallet, \
> > > instead of kwalletd.")
> > 
> > That wouldn't be what you were referring to earlier, by chance?
> 
> Yes, IIRC that was the option to enable to feature. The file implementing it was \
> called kwalletd_mac.cpp or similar.


Well, I added a +osxkeychain variant to my kdelibs4 portfile that adds \
-DMAC_USE_OSXKEYCHAIN:BOOL=ON to the configure/cmake flags, and indeed that does the \
trick. It's all a bit rough, but it could do.

That MAC_USE_OSXKEYCHAIN cmake variable was clearly included "upstream" by the \
kdelibs maintainers. I don't know if that went through a Review Request, but if so it \
could be extremely useful to know its reference/URL.

Because I do have some observations and questions (and clearly I couldn't file a new \
RR for discussing something already included in the repo):

- 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??

R.
_______________________________________________
kde-mac@kde.org
List Information: https://mail.kde.org/mailman/listinfo/kde-mac
KDE/Mac Information: http://community.kde.org/Mac


[prev in list] [next in list] [prev in thread] [next in thread]