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

[Ben Key <bkey76@gmail.com>]

On Tue, Jun 7, 2011 at 2:58 AM, Michael Albinus <michael.albinus@gmx.de> wrote:

> Reading your explanation of keychain files, it sounds natural.

Since it seems that both you and Ted Zlatanov seem to prefer the
second interpretation of the collection parameter, this evening I
rewrote the ns-keychain functions I had already written so that they
interpret the collection parameter to be an indication of what
keychain file the data should be stored in.  The values "default" or
"secrets:default" are interpreted to mean that the default keychain
should be used.  The values "login" or "secrets:Login" are interpreted
to mean that the login keychain file should be used.  Other values for
collection such as "session" or "secrets:session" are not supported at
this time.  The values "session" or "secrets:session" cause an error
with an "At this time the 'session' collection is not supported on Mac
OS X" message.  Other non-supported values simply result in the
default keychain being used.

> 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.

I could mimic this capability by storing the data in a keychain file,
such as ~/Library/Keychains/emacs-session.keychain that gets deleted
using the function SecKeychainDelete when Emacs exits.  This would
make it an Emacs session keychain.  Of course if Emacs crashes, the
keychain file would not be deleted.  If we decide to do this later, I
can add that functionality at any time without too much difficulty.
For now, I just raise an error in this case as you suggested.

Since the collection parameter is now being interpreted as an
indication of which keychain file to store the data in, I had to pick
a value for the serviceName parameter that is used by functions like
SecKeychainAddGenericPassword and SecKeychainFindGenericPassword.  I
chose the value "GNU Emacs."  Are there any objections to this?  I
could have added a parameter to allow the user to select the value of
the serviceName parameter but this would have made it necessary to
abandon my plan of adding one ns-keychain function for each secrets
API function that has the same parameters, and as near to the same
behavior, as the corresponding secrets API function.