unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Ted Zlatanov <tzz@lifelogs.com>
To: emacs-devel@gnu.org
Subject: Re: Modifying Emacs to use the Mac OS X Keychain Services
Date: Sat, 28 May 2011 10:11:41 -0500	[thread overview]
Message-ID: <87aae6yi4y.fsf@lifelogs.com> (raw)
In-Reply-To: BANLkTikT=Bk93D+_JZ9eMikDjZfMRrz_hA@mail.gmail.com

On Sat, 28 May 2011 08:00:20 -0500 Ben Key <bkey76@gmail.com> 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




  parent reply	other threads:[~2011-05-28 15:11 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-28  2:56 Modifying Emacs to use the Mac OS X Keychain Services Ben Key
2011-05-28 11:09 ` Michael Albinus
2011-05-28 13:00   ` Ben Key
2011-05-28 14:32     ` Michael Albinus
2011-05-28 17:16       ` Ben Key
2011-05-28 18:13         ` Ted Zlatanov
2011-05-28 19:38         ` Michael Albinus
2011-05-28 15:11     ` Ted Zlatanov [this message]
  -- strict thread matches above, loose matches on Subject: below --
2011-05-28 18:32 Ben Key
2011-05-30  1:08 Ben Key
2011-05-30  1:19 ` Daniel Colascione
2011-05-30 12:27 ` Ted Zlatanov
2011-06-01  2:04 Ben Key
2011-06-01  2:13 ` Ted Zlatanov
2011-06-05 18:54 ` Ben Key
2011-06-05 20:01   ` Ted Zlatanov
2011-06-06 20:26   ` Michael Albinus
2011-06-07  3:34     ` Ben Key
2011-06-07  7:58       ` Michael Albinus
     [not found]         ` <BANLkTin1DxY33iaQ5=9KJKD_gwQvsJwJ8Q@mail.gmail.com>
2011-06-08  5:50           ` Ben Key
2011-06-08 20:48             ` Ted Zlatanov
2012-07-27 15:20               ` Dave Abrahams
2012-07-28 12:16                 ` Harald Hanche-Olsen
2012-07-28 16:33                   ` Dave Abrahams
2012-07-28 16:45                     ` Harald Hanche-Olsen
2012-07-29 22:05                 ` Ted Zlatanov
2012-07-30 13:34                   ` Michael Albinus
2012-07-31 15:45                     ` Ted Zlatanov
2012-08-20 13:42                   ` Dave Abrahams
2012-08-20 13:49                   ` Dave Abrahams
2012-08-20 14:02                     ` Dave Abrahams
2011-06-05 23:23 Ben Key
2011-06-06  0:05 ` Ted Zlatanov
2011-06-11  0:30 Ben Key
2011-06-11  1:13 ` Ted Zlatanov
2011-06-12  2:28 Ben Key
2011-06-12  4:18 ` Ben Key
2011-06-12 16:40   ` Eli Zaretskii
2011-06-12 22:23     ` Ted Zlatanov
2011-06-13  3:14     ` Ben Key
2011-06-14  3:12   ` Stefan Monnier
2011-06-15  2:15     ` Ben Key
2011-06-15 15:12       ` Ted Zlatanov
2011-06-15 16:30         ` Andreas Schwab
2011-06-15 20:02           ` Ted Zlatanov
2011-06-15 23:26         ` Stefan Monnier
2011-06-17 20:31           ` Chong Yidong
2011-06-12 22:21 ` Ted Zlatanov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87aae6yi4y.fsf@lifelogs.com \
    --to=tzz@lifelogs.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).