emacs-devel
[Top][All Lists]
Advanced

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

Re: lexbind: how to replace lexical-let approach to hide secrets


From: Ted Zlatanov
Subject: Re: lexbind: how to replace lexical-let approach to hide secrets
Date: Thu, 31 Mar 2011 10:42:25 -0500
User-agent: Gnus/5.110016 (No Gnus v0.16) Emacs/24.0.50 (gnu/linux)

On Wed, 30 Mar 2011 17:12:37 -0400 Stefan Monnier <address@hidden> wrote: 

>> Slightly related: auth-source.el uses `lexical-let' to define lambda
>> accessors for secrets (so printing them, for instance, won't show a
>> password).  Will the secrets still be hidden in the lexbind branch?

SM> If you wan to hide the value, then use:

SM>   (let ((data (let ((sym (make-symbol "foo")))
SM>                 (set sym "secret")
SM>                 sym)))
SM>     (lambda () (symbol-value data)))

SM> which is similar to the what lexical-let ends up doing.

I wonder if the above approach can simply replace the `lexical-let'
macro in the lexbind branch.

On Wed, 30 Mar 2011 23:56:59 +0200 David Kastrup <address@hidden> wrote: 

DK> All of which, by necessity, contain the necessary material to get at the
DK> secret in the bytecode/closure/funcell.  Where, of course, it is
DK> reasonable easy to retrieve it.  And that is actually overkill, since
DK> you can always just call that closure.

DK> Anybody care to tell me what the point of this exercise is actually
DK> supposed to be?

1) hide secrets so they are not printed when the auth-source return data
structure is returned (as Daniel says below)

2) provide some abstraction for secrets so we can use something more
secure when it's available in Emacs

On Wed, 30 Mar 2011 15:29:12 -0700 Daniel Colascione <address@hidden> wrote: 

DC> The idea is to prevent secrets being accidentally revealed in
DC> backtraces, lisp evaluation results, and so on.

DC> By the way: I didn't notice any secret erasure code in
DC> auth-source.el. Shouldn't someone somewhere do something like this?  I
DC> didn't see anything in alloc.c that looks like it'd clear an object's
DC> bytes upon deallocation.

DC> (defun secure-erase-secret (my-secret)
DC>   (dotimes (i (length my-secret)) (setf (aref my-secret i) 0)))

password-cache.el does something like this in ELisp.  

IMHO this should be done by Emacs; the core should provide a way to tag
strings as "secret" so they are wiped on deallocation.  I think this
property should propagate when the string is copied.  

We can probably simulate some of this with closures but I think it would
be 100 times cleaner at the C level.  That way the consumer doesn't have
to wipe the secret, just release it (but he should still be able to
trigger the wipe explicitly if he knows he's done with the secret).
Also the strings can then be stored in an encoded representation so it's
not trivial to find them in memory.

Ted




reply via email to

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