emacs-devel
[Top][All Lists]
Advanced

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

Re: NaCl support for Emacs


From: Ted Zlatanov
Subject: Re: NaCl support for Emacs
Date: Mon, 09 Jan 2012 20:43:12 -0500
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.90 (gnu/linux)

On Mon, 09 Jan 2012 20:30:48 -0500 Stefan Monnier <address@hidden> wrote: 

>>>> Many places in the Emacs core (C and ELisp) could use a fast easy
>>>> encryption library for arbitrary data that supports public and
>>>> secret-key encryption, in addition to EPA/EPG that
>>>> I already mentioned.
SM> Could be.  There's no hard evidence for it yet.
>> I listed three places I think could use it, how much harder does the
>> evidence have to be?
>> - auth-source's cache of file contents
>> - EPA/EPG or something like it that does not rely on the external GPG utility
>> - general ELisp storage of secret data

SM> I don't think Emacs should reinvent every wheel.  GPG does this job well
SM> and using it means that those files can be decrypted without Emacs.

Calling out to an external process is less secure than using built-in
encryption primitives.  So while in general you're right, in this case
I'll respectfully disagree.  It may be convenient but it's not secure.

SM> I'm sure there are cases where doing the encryption in Emacs can make
SM> sense, but I'd first like to see actual code (aka "hard evidence").

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

Similarly auth-source.el returns passwords in a `lexical-let' wrapper so
they can't be leaked into the logs, they have to be evaluated, but it
doesn't attempt to obfuscate them like the code above.

Ted




reply via email to

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