emacs-devel
[Top][All Lists]
Advanced

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

Re: can emacs use the mac os x keychain?


From: Ted Zlatanov
Subject: Re: can emacs use the mac os x keychain?
Date: Thu, 29 Jul 2010 15:33:04 -0500
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux)

On Thu, 29 Jul 2010 14:52:14 -0400 David Reitter <address@hidden> wrote: 

DR> On Jul 29, 2010, at 9:17 AM, Ted Zlatanov wrote:
>> 
AR> A useful-sounding idea but seems mainly like something that would be
AR> a third-party package or maybe part of Aquamacs.  Are there any
AR> platform-independent parts of the needed functionality that the NS
AR> port lacks and Emacs on X11 or W32 has?
>> 
DR> ...
>> Assuming we get the NS port access to the Mac OS X keychain, that leaves
>> W32 as the only major platform lacking keychain support.  I don't
>> believe W32 has a standard keychain so that may be OK.

DR> I principle, the C part would be fairly simple.  There are separate
DR> functions for "internet passwords", which retrieve and store
DR> passwords for a host/port/account combination.

DR> Am I right assuming that we would need an API paralleling that
DR> provided by secrets.el?

It can be different.  auth-source.el folds the various backends under a
common interface, so I think it's best to provide simple mappings to the
underlying calls and let auth-source.el worry about the rest.  The
internet keychain calls, for instance, should be separated.

DR> There are a few issues as far as I can see:

DR> - The user is prompted via a graphical dialog to unlock a keychain
DR> (i.e., to provide a password protecting all the passwords).  When in
DR> TTY, we shouldn't do this, but unlock the keychain ourselves, i.e.,
DR> read a password from the user via a (password) minibuffer.  This
DR> sort of interaction would have to be handled by an extra Lisp layer.
DR> (Once the application is trusted, this prompt would go away.)  How
DR> is this done in GNOME?

IMHO it's acceptable to unlock only from the GUI but I'm not opposed to
what you describe.  GNOME's Seahorse works only in X, not in the TTY.

DR> - Any passwords that we obtain would probably have to be copied so
DR> we can return them as a Lisp string.  What provisions are in place
DR> in order to protect the copy and guarantee its deletion after use?

None from auth-source.el.  I don't know if ELisp has any variable tags
to do this protection but looking at the manual, I don't believe so.

Ted




reply via email to

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