From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Mon, 13 Oct 2014 12:05:00 +0300 Message-ID: <83tx38732b.fsf@gnu.org> References: <87d2ahm3nw.fsf@fencepost.gnu.org> <871tqneyvl.fsf@netris.org> <87zjd9swfj.fsf@uwakimon.sk.tsukuba.ac.jp> <87oatnqpml.fsf@uwakimon.sk.tsukuba.ac.jp> <874mvdrj45.fsf@uwakimon.sk.tsukuba.ac.jp> <20141009044917.GA19957@fencepost.gnu.org> <83lhopisfr.fsf@gnu.org> <87ppe1pldu.fsf@uwakimon.sk.tsukuba.ac.jp> <8761ft5wpo.fsf@fencepost.gnu.org> <83k349b0vj.fsf@gnu.org> <83bnph96kh.fsf@gnu.org> <87ppdwo7ll.fsf@uwakimon.sk.tsukuba.ac.jp> <83y4sk7biu.fsf@gnu.org> <87k344nzqw.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1413191155 1556 80.91.229.3 (13 Oct 2014 09:05:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 13 Oct 2014 09:05:55 +0000 (UTC) Cc: dak@gnu.org, rms@gnu.org, mikegerwitz@gnu.org, mhw@netris.org, dmantipov@yandex.ru, emacs-devel@gnu.org, handa@gnu.org, monnier@iro.umontreal.ca To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 13 11:05:47 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 1XdbZY-00062h-Ju for ged-emacs-devel@m.gmane.org; Mon, 13 Oct 2014 11:05:44 +0200 Original-Received: from localhost ([::1]:60893 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdbZY-0002hf-4i for ged-emacs-devel@m.gmane.org; Mon, 13 Oct 2014 05:05:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41886) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdbZ8-0002hW-Aj for emacs-devel@gnu.org; Mon, 13 Oct 2014 05:05:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XdbZ3-0007EO-PC for emacs-devel@gnu.org; Mon, 13 Oct 2014 05:05:18 -0400 Original-Received: from mtaout24.012.net.il ([80.179.55.180]:59794) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdbYy-0007C1-Ok; Mon, 13 Oct 2014 05:05:09 -0400 Original-Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NDD00800KVVB200@mtaout24.012.net.il>; Mon, 13 Oct 2014 11:58:48 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NDD00OUTKY02D80@mtaout24.012.net.il>; Mon, 13 Oct 2014 11:58:48 +0300 (IDT) In-reply-to: <87k344nzqw.fsf@uwakimon.sk.tsukuba.ac.jp> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.180 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:175318 Archived-At: > From: "Stephen J. Turnbull" > Cc: dak@gnu.org, > rms@gnu.org, > handa@gnu.org, > mhw@netris.org, > dmantipov@yandex.ru, > emacs-devel@gnu.org, > mikegerwitz@gnu.org, > monnier@iro.umontreal.ca > Date: Mon, 13 Oct 2014 17:24:39 +0900 > > > We shouldn't do that out of our own initiative based on academic > > considerations and examples from PHP or whatever. > > You think spam, viruses, phishing, buffer overrun exploits, and the > like are "academic considerations"? How are these relevant to this discussion (well, except for the unspecified "and the like" part)? What do these have to do with text encoding and decoding in general, and with invalid byte sequences in particular? Let's stay focused on the topic at hand, OK? > They aren't, and the attitude that users can and should take care of > themselves is *not* a selling point in this environment, except for > developers who would rather not deal with complex APIs and worse, the > finicky art of providing convenient, unobtrusive, and yet flexible UI. All I said was that I want to hear about real-life experiences with these dangers, where the attackers were able to exploit the Emacs text decoding machinery to their advantage. I know it's probably possible to concoct a synthetic use case for that (although even that was not done in this thread), but I want to see _real-life_ stories. Then we will have specific scenarios to talk about, rather than general unnamed risks, and also won't need to argue about whether "this can happen". Historically, any real-life risks that were reported on the Emacs lists were handled and fixed very quickly and without any discussions as to whether they should be fixed. Rest assured that the same will happen with the kinds of risks discussed here -- if and when someone shows us a real-life use case where these risks materialize on our watch. We arrived at the current modus operandi of Emacs wrt text encoding and decoding through sweat, blood, and tears of several major releases. It is neither an incident nor luck that complaints about these issues are rarely if at all seen on the user support forums or here, for the past 2 major releases. Changing that in response to considerations not backed up by specific user reports would be a grave mistake. If the history of Emacs development since v20.1 in this area teaches us anything, it is that we, the Emacs developers, are not good enough in making these decisions based on theoretical arguments and considerations. Suit yourself, but I, for one, don't want us to make that mistake again, ever.