Re: secret strings

[Ted Zlatanov <tzz@lifelogs.com>]

On Fri, 01 Apr 2011 16:34:23 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> think it's possible at least to encode the secret and decode it on the
>> funcall.  It will, obviously, still be somewhere in memory but at least

SM> Encoding/decoding is silly: it just hides the data, without storing it
SM> securely, so it's no better than the current "hide it behind
SM> a symbol&closure".  I.e. more work wasted for no benefit.  There are so
SM> many ways the data gets copied in memory during evaluation that encoding
SM> one string doesn't give you much guarantee that there isn't any copy of
SM> its content still lying around somewhere (for the same reason I consider
SM> clear-string to be only for use by the deluded).

OK, if I can't store the data securely and Emacs can't help me do it,
then I guess I'll note it in the auth.texi manual and move on.

I hope you and the other Emacs developers will consider secret strings
in the future in the context of a larger discussion about security in Emacs.

>> It should at least try to hide secret data and help the consumer protect
>> the secrets from accidental revealing (thus the secrets closure it uses
>> currently).  Good neighbors can warn you if you leave your door open,
>> even if it's not strictly their business.

SM> Note that instead of a closure, it can store the data in a symbol.
SM> That provides the same kind of protection (printing just prints the
SM> symbol), but is much more lightweight.

True, but I think it's not a big difference (these are rarely created).
The closure has the nice property that it has to be called and thus we
can attach more behavior to it without affecting the consumer.

Ted