From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: secret strings (was: lexbind: how to replace lexical-let approach to hide secrets) Date: Thu, 31 Mar 2011 23:41:42 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87ei5moa61.fsf_-_@lifelogs.com> References: <4D926EA9.5080509@gmail.com> <4D92AD2B.40502@gmail.com> <87lizwd9lt.fsf_-_@lifelogs.com> <87ei5n8ffi.fsf@lifelogs.com> <87hbaivju2.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1301635271 27661 80.91.229.12 (1 Apr 2011 05:21:11 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 1 Apr 2011 05:21:11 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 01 07:21:03 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Q5Wn8-0005JR-RV for ged-emacs-devel@m.gmane.org; Fri, 01 Apr 2011 07:21:03 +0200 Original-Received: from localhost ([127.0.0.1]:41479 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q5WaC-0001mJ-5Q for ged-emacs-devel@m.gmane.org; Fri, 01 Apr 2011 01:07:40 -0400 Original-Received: from [140.186.70.92] (port=59488 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q5WBL-0002I0-3m for emacs-devel@gnu.org; Fri, 01 Apr 2011 00:42:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q5WBJ-0005SO-Ty for emacs-devel@gnu.org; Fri, 01 Apr 2011 00:41:58 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:52362) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q5WBJ-0005Rj-J1 for emacs-devel@gnu.org; Fri, 01 Apr 2011 00:41:57 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Q5WBG-0001r8-Sy for emacs-devel@gnu.org; Fri, 01 Apr 2011 06:41:54 +0200 Original-Received: from c-67-186-102-106.hsd1.il.comcast.net ([67.186.102.106]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Apr 2011 06:41:54 +0200 Original-Received: from tzz by c-67-186-102-106.hsd1.il.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Apr 2011 06:41:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 52 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: c-67-186-102-106.hsd1.il.comcast.net X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:FmOi+5PDPpVC0uW1CJAMaKtaPn4= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:137968 Archived-At: On Fri, 01 Apr 2011 10:31:01 +0900 "Stephen J. Turnbull" 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