From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Carsten Mattner Newsgroups: gmane.emacs.devel Subject: Re: NaCl support for Emacs Date: Tue, 10 Jan 2012 17:01:54 +0100 Message-ID: References: <87boqh20ha.fsf@lifelogs.com> <871urc46c9.fsf@uwakimon.sk.tsukuba.ac.jp> <739bsoysp.fsf@news.eternal-september.org> <87ty47r5yt.fsf@lifelogs.com> <87k452p5u3.fsf@lifelogs.com> <87liphne9e.fsf_-_@lifelogs.com> <87fwfon7gl.fsf@lifelogs.com> <87hb04icxl.fsf@lifelogs.com> <87pqesgwnj.fsf@lifelogs.com> <87pqerg4df.fsf@lifelogs.com> <877h0zfz12.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1326211337 18368 80.91.229.12 (10 Jan 2012 16:02:17 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 10 Jan 2012 16:02:17 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 10 17:02:09 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Rke9I-0004hO-4k for ged-emacs-devel@m.gmane.org; Tue, 10 Jan 2012 17:02:08 +0100 Original-Received: from localhost ([::1]:44987 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rke9H-0007F6-G5 for ged-emacs-devel@m.gmane.org; Tue, 10 Jan 2012 11:02:07 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:39927) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rke9B-0007Ej-3h for emacs-devel@gnu.org; Tue, 10 Jan 2012 11:02:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rke96-00025E-5d for emacs-devel@gnu.org; Tue, 10 Jan 2012 11:02:01 -0500 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:46335) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rke96-000258-1o for emacs-devel@gnu.org; Tue, 10 Jan 2012 11:01:56 -0500 Original-Received: by iafj26 with SMTP id j26so1331525iaf.0 for ; Tue, 10 Jan 2012 08:01:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=gWeKeHXb9zSQte/3/0jmNttw54SzU7866vWbYoi1Jyk=; b=wTKomYQAY23TnU4mwzfsomuoqswiXZe2mTTZKs+lZBUOEI+yrGZPOrL/QSyltmor07 VpKkvYFo7i8ezxPyYapYhz7je7uELyamWk5ES9JmAoFMt/DMpN9jZupdhBR6vDMJbVhP 2vA8jDfv928ifc+1aFbNkHwjyiy5j7ZLooc6w= Original-Received: by 10.42.150.130 with SMTP id a2mr22259398icw.43.1326211315169; Tue, 10 Jan 2012 08:01:55 -0800 (PST) Original-Received: by 10.50.18.41 with HTTP; Tue, 10 Jan 2012 08:01:54 -0800 (PST) In-Reply-To: <877h0zfz12.fsf@lifelogs.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.210.169 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:147571 Archived-At: 2012/1/10 Ted Zlatanov : > On Tue, 10 Jan 2012 13:51:13 +0100 Carsten Mattner wrote: > > CM> isn't the secret to decrypt it available in emacs process space for > CM> ready retrieval? > > Not necessarily. =A0But even if it is, the attacker has to know where to > find the private key and run non-trivial code to use it. =A0The risk is > smaller than plopping the secret data in plain view. When it comes to security, you have to clearly document things like this, so that it's at least clear what's going on, and there is no false sense of safety. I tend to view security from a "the worst will happen" angle. That way you can try to minimize surprises by being aware of all the attack vectors. > CM> usually you also overwrite that memory to prevent leakage as > CM> soon as possible. > > Yes, and we've discussed how ELisp makes that hard, so this will require > work at the C level. =A0It's not trivial, absolutely. > > CM> unlocking a keychain and keeping that "safe" open for the time > CM> a user is using the environment is common practice. > > CM> aren't you going to implement something like gnome's or kde's > CM> locked keychain? > > That's a possibility but not my target currently. > > CM> there will be at least a couple users demanding integration with > CM> existing keychain systems (kde, osx, gnome, ...). > > We have KDE+GNOME in auth-source already, through the Secrets API. =A0We > also had an attempt to provide an interface to the Mac OS X keychain > last year, but I don't think it was fruitful. > > CM> git has recently implemented support for various systems with an > CM> abstraction layer and a caching "daemon". > > Yes, I've followed Jeff King's patches with great interest, although I > was absolutely swamped last year and could not test them as I wanted to. > I intend to work on integrating VC and Magit with Git's credentials, > probably with auth-source support. Also on my TODO list.