[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Modifying Emacs to use the Mac OS X Keychain Services
From: |
Dave Abrahams |
Subject: |
Re: Modifying Emacs to use the Mac OS X Keychain Services |
Date: |
Fri, 27 Jul 2012 11:20:17 -0400 |
User-agent: |
Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.1 (darwin) |
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 <address@hidden> 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
- Re: Modifying Emacs to use the Mac OS X Keychain Services,
Dave Abrahams <=