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: Thu, 09 Oct 2014 11:00:08 +0300 Message-ID: <83lhopisfr.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1412841620 1564 80.91.229.3 (9 Oct 2014 08:00:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 Oct 2014 08:00:20 +0000 (UTC) Cc: dak@gnu.org, rms@gnu.org, mhw@netris.org, dmantipov@yandex.ru, emacs-devel@gnu.org, handa@gnu.org, monnier@iro.umontreal.ca, stephen@xemacs.org To: Mike Gerwitz Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 09 10:00:12 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 1Xc8dv-0004zQ-Nf for ged-emacs-devel@m.gmane.org; Thu, 09 Oct 2014 10:00:11 +0200 Original-Received: from localhost ([::1]:40930 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xc8dv-0006TZ-Av for ged-emacs-devel@m.gmane.org; Thu, 09 Oct 2014 04:00:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59689) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xc8do-0006Os-0b for emacs-devel@gnu.org; Thu, 09 Oct 2014 04:00:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xc8dj-0001id-DC for emacs-devel@gnu.org; Thu, 09 Oct 2014 04:00:03 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:39777) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xc8de-0001hJ-91; Thu, 09 Oct 2014 03:59:54 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0ND600E002EQ6600@a-mtaout21.012.net.il>; Thu, 09 Oct 2014 10:59:52 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0ND600E5W3JS7710@a-mtaout21.012.net.il>; Thu, 09 Oct 2014 10:59:52 +0300 (IDT) In-reply-to: <20141009044917.GA19957@fencepost.gnu.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.169 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:175174 Archived-At: > Date: Thu, 9 Oct 2014 00:49:17 -0400 > From: Mike Gerwitz > Cc: rms@gnu.org, dak@gnu.org, mhw@netris.org, dmantipov@yandex.ru, > emacs-devel@gnu.org, handa@gnu.org, monnier@iro.umontreal.ca, > eliz@gnu.org > > On Thu, Oct 09, 2014 at 12:56:42PM +0900, Stephen J. Turnbull wrote: > > 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. > > Agreed. Character encoding attacks are also something that has been > exploited "in the wild". Some examples include: > > - UTF-7 character encoding to bypass filters[0] (e.g. for XSS); > - IIS WebDAV validation exploit (CVE-2009-1535);[1] and > - CAPEC-80: Using UTF-8 Encoding to Bypass Validation Logic;[2] and > - Google's XSS vulnerability, related to the first item in this list.[3] > > Note that not all of the above may be applicable to the specifics of this > discussion---the point is to convey, generally, that character encoding > poses serious threats when improperly handled. Though this discussion seems > to be about what is "improper". Aren't you again confusing the application level with the lower "engine" level? Applications, which do interpret the text, should indeed be aware of these issues. (For the purposes of this discussion, "application" means Lisp code that processes text, or presents it to the user, or acts according to user responses.) But the "engine" must be able to handle raw bytes, including invalid UTF-8 sequences, unless told otherwise. Any other default will unduly punish the innocent majority on behalf of the evil minority. > With regards to passing raw input to other systems: this isn't necessarily > Unicode related (unless an invalid sequence contains a null byte), but > serves to illustrate the point that Mark is trying to make: there is a > well-known issue in PHP whereby passing a null byte as a parameter to a > script (e.g. via HTTP GET/POST) opens up a number of attacks. Specifically, > PHP handles null bytes in strings (by storing the string length as part of > the struct that holds the string). However, it makes calls directly to libc. > So, if an unvalidated input $foo contains "../../../../etc/group\000", and > PHP makes a call to `fopen' with the path "/webroot/modules/$foo/index.php", > the result would be opening "/webroot/modules/../../../../etc/group". So what would you have Emacs do when I'm editing a file with binary nulls: ask me for each save whether I really mean it, and lecture me about possible security implications? The encoding routines have no idea whether they are encoding a PHP script, much less whether it will be sent via HTTP. > I can dig up more examples, but hopefully some of these help to illustrate > the severity of ignoring character encoding concerns. Please do, but (a) please make the examples be relevant to what Emacs does with decoding and encoding external bytestreams, and (b) please suggest what you think Emacs should do in those cases instead of what it does now. Otherwise, this discussion is much less constructive than it could be, because our concerns are with how the discussed issues will or should affect Emacs.