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 13:51:13 +0100 Message-ID: References: <87lipl22xm.fsf@lifelogs.com> <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> 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 1326199892 27220 80.91.229.12 (10 Jan 2012 12:51:32 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 10 Jan 2012 12:51:32 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 10 13:51:28 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 1RkbAm-0004Kf-3e for ged-emacs-devel@m.gmane.org; Tue, 10 Jan 2012 13:51:28 +0100 Original-Received: from localhost ([::1]:46838 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RkbAl-0000UE-Ap for ged-emacs-devel@m.gmane.org; Tue, 10 Jan 2012 07:51:27 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:39712) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RkbAe-00007e-9f for emacs-devel@gnu.org; Tue, 10 Jan 2012 07:51:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RkbAY-0004Jv-2j for emacs-devel@gnu.org; Tue, 10 Jan 2012 07:51:20 -0500 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:48729) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RkbAX-0004Jp-U9 for emacs-devel@gnu.org; Tue, 10 Jan 2012 07:51:14 -0500 Original-Received: by iafj26 with SMTP id j26so1070214iaf.0 for ; Tue, 10 Jan 2012 04:51:13 -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=DKSjuqpbErpwRNWR+jcQ6GHQjem6Z2oxAr8U0+SKUiw=; b=LyGZyoPLix0W7oIkTehk+atOiTdx95psfg+QHLvC4U8j6TVVseo2PljXOMMPVmSP69 3GexQc1674be8V3VB9AaNQxZTWoLcO0UIdFEiBnlBG5kzVSrncp9m3WQg/oF9iRs0jpb oU19Z/kup1YGLtk1D5T0nrf5I1GxQ4uOj3+h8= Original-Received: by 10.50.88.230 with SMTP id bj6mr2277177igb.26.1326199873091; Tue, 10 Jan 2012 04:51:13 -0800 (PST) Original-Received: by 10.50.18.41 with HTTP; Tue, 10 Jan 2012 04:51:13 -0800 (PST) In-Reply-To: <87pqerg4df.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:147564 Archived-At: 2012/1/10 Ted Zlatanov : > On Mon, 09 Jan 2012 22:21:19 -0500 Stefan Monnier wrote: > >>> Argh. =A0The auth-source cache is already implemented as a hack, is tha= t >>> hard enough evidence? =A0Quoting the relevant bit from >>> `auth-source-netrc-parse': > >>> #+begin_src lisp >>> ;; cache all netrc files (used to be just .gpg files) >>> ;; Store the contents of the file heavily encrypted in memory. >>> ;; (note for the irony-impaired: they are just obfuscated) >>> (aput 'auth-source-netrc-cache file >>> (list :mtime (nth 5 (file-attributes file)) >>> :secret (lexical-let ((v (mapcar '1+ (buffer-string)))) >>> (lambda () (apply 'string (mapcar '1- v)))))) >>> #+end_src > > SM> Not only I'm not worried about that, but I'm not sure libnettle (or a= ny > SM> other encryption library) would help you fix the underlying problem: > SM> Emacs needs to be able to recover the password for later use anyway, = so > SM> anything we do can only ever be obfuscation, AFAIK. =A0Maybe there's = some > SM> clever way to do better, but again, for lack of hard evidence > SM> I'm unconvinced. > > With true encryption with libnettle, we can encrypt the secret in > memory, on the wire, and on disk so a casual attacker doesn't have the isn't the secret to decrypt it available in emacs process space for ready retrieval? usually you also overwrite that memory to prevent leakage as soon as possible. unlocking a keychain and keeping that "safe" open for the time a user is using the environment is common practice. aren't you going to implement something like gnome's or kde's locked keychain? there will be at least a couple users demanding integration with existing keychain systems (kde, osx, gnome, ...). git has recently implemented support for various systems with an abstraction layer and a caching "daemon". > chance to grab it. =A0This should hook into the Lisp object printer, for > instance, so it's effortless to print and read encrypted objects. > > I'm worried about treating obfuscation as "good enough" security. =A0That > has a history of backfiring. =A0Would it convince you to show an attack > that succeeds with obfuscation but fails with true encryption? > > I know Emacs is not designed with security in mind. =A0We have to start > somewhere; this will at least harden the outer shell. =A0You may not be > worried about it, but I am. when Emacs was written legend tells that passwords were not in common use in the timeshare environment Richard worked with.