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: Re: secret strings Date: Fri, 01 Apr 2011 15:08:19 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87pqp5wx8s.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> <87ei5moa61.fsf_-_@lifelogs.com> <87hbaia58a.fsf@uwakimon.sk.tsukuba.ac.jp> <87aagansj0.fsf@lifelogs.com> <87r59mm3z7.fsf@uwakimon.sk.tsukuba.ac.jp> <87pqp657le.fsf@lifelogs.com> <87oc4qlzjb.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 1301688629 10198 80.91.229.12 (1 Apr 2011 20:10:29 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 1 Apr 2011 20:10:29 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 01 22:10:23 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 1Q5kfn-0007b2-9J for ged-emacs-devel@m.gmane.org; Fri, 01 Apr 2011 22:10:23 +0200 Original-Received: from localhost ([127.0.0.1]:38652 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q5kfm-0007PQ-EL for ged-emacs-devel@m.gmane.org; Fri, 01 Apr 2011 16:10:22 -0400 Original-Received: from [140.186.70.92] (port=55025 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q5ke2-0006lu-0y for emacs-devel@gnu.org; Fri, 01 Apr 2011 16:08:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q5ke0-00034F-QJ for emacs-devel@gnu.org; Fri, 01 Apr 2011 16:08:33 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:36370) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q5ke0-00033v-GF for emacs-devel@gnu.org; Fri, 01 Apr 2011 16:08:32 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Q5kdy-000694-D5 for emacs-devel@gnu.org; Fri, 01 Apr 2011 22:08:30 +0200 Original-Received: from 38.98.147.130 ([38.98.147.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Apr 2011 22:08:30 +0200 Original-Received: from tzz by 38.98.147.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Apr 2011 22:08:30 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 36 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 38.98.147.130 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:Fyc5f4bcy7zpAD1l13pG5Yns35U= 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:138026 Archived-At: On Sat, 02 Apr 2011 01:14:16 +0900 "Stephen J. Turnbull" wrote: SJT> Ted Zlatanov writes: >> OK. I'll buy that. So how, then, does the the producer, the >> auth-source API, encourage consumers to wipe their secrets? SJT> That depends on the security model, it seems to me. For some SJT> purposes, ROT13, with no secret at all, is sufficient "security". In SJT> other cases, the user is given a secret to be used once (eg, a SJT> temporary password). In other cases, the user may never see the SJT> secret at all (public key methods). OK. All the code is already written to hide it in a lexical closure. I 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 not as visibly. Then the consumer can use `with-secret-strings' in their local scope. SJT> The problem, as I see it, is that the auth-source doesn't know what SJT> the consumer is going to do with it, or how long the secret will SJT> remain valid. I don't really see how this is the auth-source's SJT> business. 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. SJT> The `with-secret-strings' macro I suggested is the only fairly generic SJT> kind of thing I can think of, but it's not really very general. I'll put it in auth-source.el and suggest it in auth.texi; I'll also crawl through the places that use auth-source and rewrite them to use the macro. So it will be useful--thank you for the suggestion. Ted