[Top][All Lists]

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

secret strings (was: lexbind: how to replace lexical-let approach to hid

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

On Fri, 01 Apr 2011 10:31:01 +0900 "Stephen J. Turnbull" <address@hidden> 

SJT> Ted Zlatanov writes:
>> IMHO this should be done by Emacs; the core should provide a way to tag
>> strings as "secret" so they are wiped on deallocation.

SJT> I don't see why this is better than the method already used, since you
SJT> would have to use a different call to make such strings.

The consumer wouldn't have to explicitly track and clear such strings.
I think this is better and *safer* than asking the consumer to do it.

These strings would be made differently by the producer (the auth-source
API in this case) using some Emacs core functionality.  The consumer
doesn't know they are different from ordinary strings.  They print like
normal strings.  They simply get explicitly wiped on deallocation and
*maybe* get stored in an obfuscated way.

SJT> In the end it's up to the application to manage these secrets.

I strongly disagree that the consumer should have to wipe secrets when
done with them.  That simply shifts the burden of managing secrets
without easing it.

>> I think this property should propagate when the string is copied.

SJT> But what about the storage the string is copied from?

Obviously data has to come from somewhere.  It can come from the
environment and from files and from IPC and from process pipes.  Emacs
can provide functions that read directly from those sources into a
secret string.

Again, this is to manage wipe on deallocation and maybe provide
obfuscated storage, not a comprehensive security solution.  I have no
illusions that Emacs Lisp can ever be made secure and no desire to see
that, either.

SJT> I think this is overkill, and won't really help naive users keep
SJT> their secrets.

I'm not sure where "naive users" came into the picture and how we're
supposed to help them with this proposal.  It only benefits the
consumer, which usually is an application, and the producer, which in my
case is the auth-source API.  Users should not see a difference or care.

Hiding secrets from backtraces and printing is another matter.  That we
can do with `lexical-let' or the approach Stefan showed so I think it's
a solved problem.  I've changed the subject to reflect we're discussing
"secret strings" now, though the name is not very good.


reply via email to

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