Re: secret strings

[Stefan Monnier <monnier@iro.umontreal.ca>]

> 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

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

> 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.

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


        Stefan