From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dave Abrahams Newsgroups: gmane.emacs.devel,gmane.emacs.gnus.general Subject: Re: Modifying Emacs to use the Mac OS X Keychain Services Date: Fri, 27 Jul 2012 11:20:17 -0400 Message-ID: References: <8739jmso4c.fsf@gmx.de> <87y61ekr8y.fsf@gmx.de> <87tyc0camo.fsf@lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1343402455 7841 80.91.229.3 (27 Jul 2012 15:20:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 27 Jul 2012 15:20:55 +0000 (UTC) Cc: ding@gnus.org To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 27 17:20:53 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SumLT-0000Of-TZ for ged-emacs-devel@m.gmane.org; Fri, 27 Jul 2012 17:20:52 +0200 Original-Received: from localhost ([::1]:59435 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SumLT-0005dT-2b for ged-emacs-devel@m.gmane.org; Fri, 27 Jul 2012 11:20:51 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:37103) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SumLQ-0005dD-F9 for emacs-devel@gnu.org; Fri, 27 Jul 2012 11:20:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SumLG-0005o8-7k for emacs-devel@gnu.org; Fri, 27 Jul 2012 11:20:48 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:50240) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SumLG-0005nb-0t for emacs-devel@gnu.org; Fri, 27 Jul 2012 11:20:38 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SumLF-0000F3-4i for emacs-devel@gnu.org; Fri, 27 Jul 2012 17:20:37 +0200 Original-Received: from 207-172-223-249.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com ([207.172.223.249]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Jul 2012 17:20:37 +0200 Original-Received: from dave by 207-172-223-249.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Jul 2012 17:20:37 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 83 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 207-172-223-249.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.1 (darwin) Cancel-Lock: sha1:qcc8xzl24vo8aAF0W/OZIrYLPxg= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:151921 gmane.emacs.gnus.general:82097 Archived-At: 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 to get the password for my mail server. TIA, Dave on Wed Jun 08 2011, Ted Zlatanov wrote: > On Wed, 8 Jun 2011 00:50:50 -0500 Ben Key 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