emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Modifying Emacs to use the Mac OS X Keychain Services


From: Ted Zlatanov
Subject: Re: Modifying Emacs to use the Mac OS X Keychain Services
Date: Sat, 28 May 2011 10:11:41 -0500
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux)

On Sat, 28 May 2011 08:00:20 -0500 Ben Key <address@hidden> wrote: 

BK> First, to give a little background.  Several months ago there was a request
BK> to have auth-source.el use the Mac OS X keychain functions (see
BK> http://lists.gnu.org/archive/html/emacs-devel/2011-03/msg00486.html).  These
BK> functions are documented at
BK> 
http://developer.apple.com/library/mac/#documentation/Security/Conceptual/keychainServConcepts/03tasks/tasks.html.
BK> I agreed to do it but then got busy and later forgot about it.  I want to
BK> finally keep my promise this weekend.

BK> When I started looking into what would be needed to complete this task the
BK> first thing I noticed is that auth-source.el makes use of the functions in
BK> secrets.el I mentioned if the user customizes the auth-sources variable to
BK> include the secrets API.  Since the Keychain Services API provides
BK> functionality similar to that provided by the org.freedesktop.secrets
BK> interface I figured that secrets.el would be a logical place to put the
BK> change.  Putting the code there also makes it available to packages other
BK> than Gnus.  Of course I could just define another authentication source in
BK> auth-source.el as you suggest.

BK> I thought that extending secrets.el was the more logical choice since much
BK> like the org.freedesktop.secrets interface, the Keychain Services API
BK> provides a Login key chain along with the possibility of using an
BK> application defined keychain.

They are superficially similar but internally very different (the
Keychain Services API uses a C API; the Secrets API uses D-BUS and an
entirely different protocol if I understand correctly).  So I think it's
better to supply a ELisp interface to the basic Keychain Services API,
which should be a simpler task than adapting secrets.el to use the
Keychain Services API.  You can try to model your code after the
secrets.el functions (list collections, search for items, etc.) but if
it becomes an impediment, just follow the C API you're adapting.

Ted




reply via email to

[Prev in Thread] Current Thread [Next in Thread]