<div dir="ltr">This reminds me, the configure script for subversion checks for both kwallet support and for OSX KeyChain support... is there any point in configuring it with both if kwallet is just using the system keychain as a backend in the first place?<div>

<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 29, 2014 at 6:06 AM, "René J.V. Bertin" <span dir="ltr"><<a href="mailto:rjvbertin@gmail.com" target="_blank">rjvbertin@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Morning!<br>
<br>
On Jul 29, 2014, at 10:01, Frank Osterfeld wrote:<br>
<br>
><br>
> On 28 Jul 2014, at 23:30, René J.V. Bertin <<a href="mailto:rjvbertin@gmail.com">rjvbertin@gmail.com</a>> wrote:<br>
>><br>
>> I just stumbled across a Cmake variable/flag, MAC_USE_OSXKEYCHAIN :<br>
>><br>
>>> option(MAC_USE_OSXKEYCHAIN "On OS X, use the keychain as backend for kwallet, instead of kwalletd.")<br>
>><br>
>> That wouldn't be what you were referring to earlier, by chance?<br>
><br>
> Yes, IIRC that was the option to enable to feature. The file implementing it was called kwalletd_mac.cpp or similar.<br>
<br>
<br>
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.<br>
<br>
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.<br>


<br>
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):<br>
<br>
- 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?<br>
<br>
- 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.<br>


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.)<br>


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


<br>
R.<br>
_______________________________________________<br>
macports-users mailing list<br>
<a href="mailto:macports-users@lists.macosforge.org">macports-users@lists.macosforge.org</a><br>
<a href="https://lists.macosforge.org/mailman/listinfo/macports-users" target="_blank">https://lists.macosforge.org/mailman/listinfo/macports-users</a><br>
</blockquote></div><br></div>