Re: NaCl support for Emacs

[Carsten Mattner <carstenmattner@googlemail.com>]

2012/1/10 Ted Zlatanov <tzz@lifelogs.com>:
> On Tue, 10 Jan 2012 13:51:13 +0100 Carsten Mattner <carstenmattner@googlemail.com> wrote:
>
> CM> isn't the secret to decrypt it available in emacs process space for
> CM> ready retrieval?
>
> Not necessarily.  But even if it is, the attacker has to know where to
> find the private key and run non-trivial code to use it.  The 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.  It'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.  We
> 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.