emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NaCl support for Emacs


From: Carsten Mattner
Subject: Re: NaCl support for Emacs
Date: Tue, 10 Jan 2012 13:51:13 +0100

2012/1/10 Ted Zlatanov <address@hidden>:
> On Mon, 09 Jan 2012 22:21:19 -0500 Stefan Monnier <address@hidden> wrote:
>
>>> Argh.  The auth-source cache is already implemented as a hack, is that
>>> hard enough evidence?  Quoting 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 any
> 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.  Maybe 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.  This 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.  That
> has a history of backfiring.  Would 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.  We have to start
> somewhere; this will at least harden the outer shell.  You 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]