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

[Dave Abrahams <dave@boostpro.com>]

Did anything come of this?  I am really tired of typing in my GPG key
every time I start Gnus.  I'd be more than happy to have a solution that
just used /usr/bin/security to look up the password; I don't need more
security than that.

I looked a bit at the "secrets" API but could understand it easily
enough to code something up.  I just want Emacs to run

   /usr/bin/security --find-internet-password -gs <hostname> <username>

to get the password for my mail server.

TIA,

Dave

on Wed Jun 08 2011, Ted Zlatanov <tzz-AT-lifelogs.com> wrote:

> On Wed, 8 Jun 2011 00:50:50 -0500 Ben Key <bkey76@gmail.com> wrote: 
>
> BK> I rewrote the ns-keychain functions I had already written so that
> BK> they interpret the collection parameter to be an indication of what
> BK> keychain file the data should be stored in.  The values "default" or
> BK> "secrets:default" are interpreted to mean that the default keychain
> BK> should be used.  The values "login" or "secrets:Login" are
> BK> interpreted to mean that the login keychain file should be
> BK> used.  Other values for collection such as "session" or
> BK> "secrets:session" are not supported at this time.  The values
> BK> "session" or "secrets:session" cause an error with an "At this time
> BK> the 'session' collection is not supported on Mac OS X" message.
>
> This is good, but the error should be simply "The collection %s could
> not be found" for any invalid collection, not just "session".
>
> BK>  Other non-supported values simply result in the default keychain
> BK> being used.
>
> Please throw an error if the requested keychain doesn't exist, same as
> above.
>
>>> The major idea of the "session" collection is to NOT store secrets
>>> permanently. Therefore, I would recommend that you raise an error "not
>>> available" or something like this, if somebody uses the "session"
>>> collection in your case.
>
> BK> I could mimic this capability by storing the data in a keychain file,
> BK> such as ~/Library/Keychains/emacs-session.keychain that gets deleted
> BK> using the function SecKeychainDelete when Emacs exits.  This would
> BK> make it an Emacs session keychain.  Of course if Emacs crashes, the
> BK> keychain file would not be deleted.
>
> I don't think this is useful and introduces unwanted security risks.
> There's no need to mimic the Secrets API "session" transient storage if
> it's not directly supported by the Keychain Services.
>
> BK> Since the collection parameter is now being interpreted as an
> BK> indication of which keychain file to store the data in, I had to pick
> BK> a value for the serviceName parameter that is used by functions like
> BK> SecKeychainAddGenericPassword and SecKeychainFindGenericPassword.  I
> BK> chose the value "GNU Emacs."  Are there any objections to this?
>
> Yes, please make it configurable.
>
> BK>  I could have added a parameter to allow the user to select the
> BK> value of the serviceName parameter but this would have made it
> BK> necessary to abandon my plan of adding one ns-keychain function for
> BK> each secrets API function that has the same parameters, and as near
> BK> to the same behavior, as the corresponding secrets API function.
>
> Don't be afraid of diverging from the Secrets API.  The Keychain
> Services API is not the same thing, we know that.  Please add that
> parameter to the calls.
>
> Are you providing both SecKeychain*GenericPassword and
> SecKeychain*InternetPassword?
>
> Ted

-- 
Dave Abrahams
BoostPro Computing                  Software Development        Training
http://www.boostpro.com             Clang/LLVM/EDG Compilers  C++  Boost