From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Thu, 09 Oct 2014 12:56:42 +0900 Message-ID: <874mvdrj45.fsf@uwakimon.sk.tsukuba.ac.jp> References: <54193A70.9020901@member.fsf.org> <87lhp6h4zb.fsf@panthera.terpri.org> <87k34qo4c1.fsf@fencepost.gnu.org> <54257C22.2000806@yandex.ru> <83iokato6x.fsf@gnu.org> <87wq8pwjen.fsf@uwakimon.sk.tsukuba.ac.jp> <837g0ptnlj.fsf@gnu.org> <87r3yxwdr6.fsf@uwakimon.sk.tsukuba.ac.jp> <87tx3tmi3t.fsf@fencepost.gnu.org> <834mvttgsf.fsf@gnu.org> <87lhp5m99w.fsf@fencepost.gnu.org> <87h9ztm5oa.fsf@fencepost.gnu.org> <87d2ahm3nw.fsf@fencepost.gnu.org> <871tqneyvl.fsf@netris.org> <87zjd9swfj.fsf@uwakimon.sk.tsukuba.ac.jp> <87oatnqpml.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1412827063 5555 80.91.229.3 (9 Oct 2014 03:57:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 Oct 2014 03:57:43 +0000 (UTC) Cc: dak@gnu.org, mhw@netris.org, dmantipov@yandex.ru, emacs-devel@gnu.org, handa@gnu.org, monnier@iro.umontreal.ca, eliz@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 09 05:57:33 2014 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 1Xc4r6-0007G1-6N for ged-emacs-devel@m.gmane.org; Thu, 09 Oct 2014 05:57:32 +0200 Original-Received: from localhost ([::1]:39988 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xc4r5-0000w5-RX for ged-emacs-devel@m.gmane.org; Wed, 08 Oct 2014 23:57:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48433) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xc4qn-0000ut-He for emacs-devel@gnu.org; Wed, 08 Oct 2014 23:57:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xc4qb-0002na-Bp for emacs-devel@gnu.org; Wed, 08 Oct 2014 23:57:13 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:43188) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xc4qL-0002dk-H4; Wed, 08 Oct 2014 23:56:45 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 8C67A1C3A38; Thu, 9 Oct 2014 12:56:42 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 7E1611A2888; Thu, 9 Oct 2014 12:56:42 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 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:175160 Archived-At: Richard Stallman writes: > If you demonstrate that this claim is valid, I will be concerned. *sigh* Be unconcerned. The world is a *lot* more hostile today than it was in the days when you posted your passwords on the 'net. > It would be a pain in the neck if Emacs strings were something > different from Guile strings. Sure. Security comes at cost. That's part of why credit cards charge a minumum of 5% over prime rate, and why people lose hundreds of millions of dollars a year to Internet scams: somebody didn't want to pay that cost, so imposed the risk on others. The risk is almost invisiblly small in a monolithic Emacs, it's true. But a Guile-based Emacs is no longer monolithic. It becomes a component directly connected to a much larger system of Guile modules, whose purposes and uses the Emacs developers do not know. Evidently some leading Emacs developers are unwilling to care at all about those unknown purposes and use cases. If I were a Guile maintainer, I would be concerned about adding features requested by Emacs. > If you want to argue that security justifies this pain, Sorry, no. If you want to use a Guile maintained by Mark, you're going to have to convince him that the benefits of having Guile implement string properties natively (rather than in the Emacs module running on top of Guile) is worth overriding his justified paranoia. I'm trying to convince you and other Emacs developers that you're going to have to be more sympathetic to security if you want to get such features into Guile. > you need to show it is real security and really does a useful job. I suspect I can't give you a convincing example, because I haven't studied the Guile modules "at risk", and in any case, most real risks would require Guile modules that take advantage of text properties (of which there are obviously none) or an Emacs -> Guile security code -> Emacs passage, where the second Emacs instance "trusts" the code because the Guile security code has validated it, but that's not possible yet either. However, here are a couple of analogies. Even a feature as simple as ".." representing the parent directory has been used in disastrous network breakins. The danger of ".." is obvious in retrospect, but the developers of web servers (several) were taken unaware because they used system calls to traverse paths, and those calls authomatically implemented "..". Sensitive user data (such as password files) was leaked. Or how about the recent bash lossage? s-expressions are just Lisp data, and could be placed in a property. Older security code that does not validate properties might pass arbitrary code (because it doesn't look at it) to a module that expects to receive a symbol, eval's it, and voila! you're owned, just as any CGI implemented as a shell script on a host where /bin/sh is a symlink to bash can own you. Evaluating functions stored in environment variables is not a POSIX sh feature; if bash's "sh compatibility" mode actually implemented compatibility, this exploit would be impossible. AFAIK setting POSIX_ME_HARDER doesn't help. So there you are. That's the best I can do.