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

[Ted Zlatanov]

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