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: opaque data types Date: Fri, 07 Jun 2013 12:01:59 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87y5alq58o.fsf@lifelogs.com> References: <51AE71DB.8060005@yandex.ru> <87zjv41uer.fsf@lifelogs.com> <878v2oxwhr.fsf@lifelogs.com> <87r4gfa8nw.fsf@uwakimon.sk.tsukuba.ac.jp> <87fvwvwgg5.fsf@lifelogs.com> <87li6maa9r.fsf@uwakimon.sk.tsukuba.ac.jp> <87sj0uqdhm.fsf_-_@lifelogs.com> <87a9n2oxu6@ch.ristopher.com> <87bo7iqad2.fsf@lifelogs.com> <87txlancx8@ch.ristopher.com> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1370620939 746 80.91.229.3 (7 Jun 2013 16:02:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 7 Jun 2013 16:02:19 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 07 18:02:20 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ukz7L-0005cf-6g for ged-emacs-devel@m.gmane.org; Fri, 07 Jun 2013 18:02:19 +0200 Original-Received: from localhost ([::1]:52823 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ukz7K-0000pp-Qz for ged-emacs-devel@m.gmane.org; Fri, 07 Jun 2013 12:02:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42080) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ukz7G-0000pU-38 for emacs-devel@gnu.org; Fri, 07 Jun 2013 12:02:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ukz7E-0003Ge-Fk for emacs-devel@gnu.org; Fri, 07 Jun 2013 12:02:14 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:49704) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ukz7D-0003CG-VS for emacs-devel@gnu.org; Fri, 07 Jun 2013 12:02:12 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Ukz7C-0005VA-5X for emacs-devel@gnu.org; Fri, 07 Jun 2013 18:02:10 +0200 Original-Received: from pool-72-93-26-80.bstnma.east.verizon.net ([72.93.26.80]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 07 Jun 2013 18:02:10 +0200 Original-Received: from tzz by pool-72-93-26-80.bstnma.east.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 07 Jun 2013 18:02:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 28 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: pool-72-93-26-80.bstnma.east.verizon.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" Mail-Copies-To: never User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:hedxSkczdjAQ7iasQKi/Y9NqV+s= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:160230 Archived-At: On Fri, 7 Jun 2013 16:44:18 +0100 (BST) Christopher Schmidt wrote: CS> Ted Zlatanov writes: >> To store passwords and other sensitive data in a way so they are not >> trivial to extract. We've had some previous emacs-devel discussions >> about this. CS> Can you please point me to the discussion? At least some of it was covered in the thread around http://lists.gnu.org/archive/html/emacs-devel/2012-01/msg00407.html CS> Considering we are talking about a regular userspace application with no CS> distributed components I do not see any advantage at all by encrypting CS> passwords in memory. How does interposing a function to extract CS> passwords from a new inbuild type increase security at all? By making it less trivial to extract them. The opaque type makes it possible to change the implementation if better ways are available on a platform, e.g. the Mac OS X keychain or the Secrets API or the W32 keychain. The fallback mechanism can at least make it a little harder to get someone's passwords. CS> Who's your attacker anyway? Do we have to do risk assessments too? Ted