all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ted Zlatanov <tzz@lifelogs.com>
To: emacs-devel@gnu.org
Subject: secret strings (was: lexbind: how to replace lexical-let approach to hide secrets)
Date: Thu, 31 Mar 2011 23:41:42 -0500	[thread overview]
Message-ID: <87ei5moa61.fsf_-_@lifelogs.com> (raw)
In-Reply-To: 87hbaivju2.fsf@uwakimon.sk.tsukuba.ac.jp

On Fri, 01 Apr 2011 10:31:01 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

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.

Ted




  reply	other threads:[~2011-04-01  4:41 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-29 21:44 lexbind ready for merge Stefan Monnier
2011-03-29 23:43 ` Daniel Colascione
2011-03-30  1:22   ` Stefan Monnier
2011-03-30  4:10     ` Daniel Colascione
2011-03-30 11:35       ` Juanma Barranquero
2011-03-30 13:24         ` lexbind: how to replace lexical-let approach to hide secrets (was: lexbind ready for merge) Ted Zlatanov
2011-03-30 21:12           ` lexbind: how to replace lexical-let approach to hide secrets Stefan Monnier
2011-03-30 21:56             ` David Kastrup
2011-03-30 22:29               ` Daniel Colascione
2011-03-31 15:42             ` Ted Zlatanov
2011-04-01  1:31               ` Stephen J. Turnbull
2011-04-01  4:41                 ` Ted Zlatanov [this message]
2011-04-01  5:52                   ` secret strings (was: lexbind: how to replace lexical-let approach to hide secrets) Stephen J. Turnbull
2011-04-01 11:02                     ` secret strings Ted Zlatanov
2011-04-01 14:38                       ` Stephen J. Turnbull
2011-04-01 15:12                         ` Ted Zlatanov
2011-04-01 16:14                           ` Stephen J. Turnbull
2011-04-01 20:08                             ` Ted Zlatanov
2011-04-01 20:34                               ` Stefan Monnier
2011-04-01 21:25                                 ` Ted Zlatanov
2011-04-01 14:59                       ` Stefan Monnier
2011-03-30 15:09         ` lexbind ready for merge Daniel Colascione
2011-03-30 15:20           ` Juanma Barranquero
2011-03-30 14:26       ` Stefan Monnier
2011-03-30  7:28 ` Tassilo Horn
2011-03-30 11:30   ` Eli Zaretskii
2011-03-30 13:10     ` Tassilo Horn
2011-03-30 13:17     ` Ted Zlatanov
2011-03-30 14:29   ` Stefan Monnier
2011-03-30 14:54     ` Tassilo Horn
2011-03-31  1:02       ` Stephen J. Turnbull
2011-03-30 16:11     ` Lars Magne Ingebrigtsen
2011-03-30 17:10       ` Tassilo Horn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ei5moa61.fsf_-_@lifelogs.com \
    --to=tzz@lifelogs.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.