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: Sun, 12 Oct 2014 23:49:14 +0900 Message-ID: <87zjd1ny1h.fsf@uwakimon.sk.tsukuba.ac.jp> References: <54193A70.9020901@member.fsf.org> <871tqneyvl.fsf@netris.org> <87d2a54t1m.fsf@yeeloong.lan> <83lhotme1e.fsf@gnu.org> <871tql17uw.fsf@yeeloong.lan> <838uktm9gw.fsf@gnu.org> <87h9zgarvp.fsf@fencepost.gnu.org> <83y4srjaot.fsf@gnu.org> <83r3yhiu8c.fsf@gnu.org> <83siiw9c6t.fsf@gnu.org> <83zjd3846e.fsf@gnu.org> <8738auyxke.fsf@netris.org> <874mvaoys7.fsf@uwakimon.sk.tsukuba.ac.jp> <87h9z91y52.fsf@fencepost.gnu.org> <871tqdpjoi.fsf@uwakimon.sk.tsukuba.ac.jp> <874mv91n6a.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1413125401 9225 80.91.229.3 (12 Oct 2014 14:50:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 12 Oct 2014 14:50:01 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 12 16:49:54 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 1XdKT3-0001zj-EX for ged-emacs-devel@m.gmane.org; Sun, 12 Oct 2014 16:49:53 +0200 Original-Received: from localhost ([::1]:57496 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdKT3-0004Qy-5i for ged-emacs-devel@m.gmane.org; Sun, 12 Oct 2014 10:49:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44783) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdKSj-0004O5-4L for emacs-devel@gnu.org; Sun, 12 Oct 2014 10:49:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XdKSb-0005vn-LD for emacs-devel@gnu.org; Sun, 12 Oct 2014 10:49:33 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:57316) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdKST-0005sr-IN; Sun, 12 Oct 2014 10:49:17 -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 C06CF1C39AB; Sun, 12 Oct 2014 23:49:14 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id B02B81A2888; Sun, 12 Oct 2014 23:49:14 +0900 (JST) In-Reply-To: <874mv91n6a.fsf@fencepost.gnu.org> 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:175289 Archived-At: David Kastrup writes: > I don't buy the claims that the ability to faithfully represent > arbitrary input in a consistent and reprodusible manner fully supported > by all internal operations and kept unconfusable with other characters > equals "carelessness in security". Good for you! I wouldn't either -- if any such claim had ever been made. > Now you claim that you want such support but only if very explicitly > requested, Yes, that is my own preference. I could easily be wrong for the general user, as I've been rolling handlers for broken encoding usage for 25 years. However, I've also seen the damage that can be done when a component of a system makes a virtue of transmitting everything verbatim, and believe it's best to start secure. > making it a second-class citizen. Non-default is *not* second-class. And if warranted, defaults can be changed. I just prefer starting with safe defaults. Although you personally may suffer due to the applications you work on, I suspect you will be surprised at the lack of outcry if you change the default judiciously, case by case. > I've also already given an example of GUILE code that is unable to > losslessly pass a string through a string port (the standard > mechanism for _accumulating_ a string). Presumably improving that situation is precisely why Mark is here. > Again, this is an outcome of the "let's cater primarily for good > encodings" philosophy that is at the bottom of _many_ security > problems. Sigh. It is *Emacs* that assumes the world is full of valid data, and happily shovels any hazmat it receives on to the next user or program without validation. And you're right, it *is* a security problem. Not just denial of service, either. You say that behavior is what Emacs users want, and maybe it is. Because most of the time the data is "nearly" valid and the defects are "insignificant", and hardly a security problem. It's the "worse is better" philosophy.[1] But the rest of the software development world is going in the opposite direction. "In God we trust. All others, present photo ID." Maybe they have figured something out? Heck, even Emacs is moving in the direction of defending *itself* from invalid data in other ways (thank you, Ted Z!) Footnotes: [1] Read Gabriel's essay of that title before taking that as an insult.