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: Mon, 06 Oct 2014 12:34:40 +0900 Message-ID: <87zjd9swfj.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1412566528 8320 80.91.229.3 (6 Oct 2014 03:35:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 Oct 2014 03:35:28 +0000 (UTC) Cc: dak@gnu.org, Mark H Weaver , 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 Mon Oct 06 05:35:20 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 1Xaz4w-0001F8-8K for ged-emacs-devel@m.gmane.org; Mon, 06 Oct 2014 05:35:18 +0200 Original-Received: from localhost ([::1]:49819 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xaz4t-0006ev-Sh for ged-emacs-devel@m.gmane.org; Sun, 05 Oct 2014 23:35:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52521) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xaz4j-0006be-QW for emacs-devel@gnu.org; Sun, 05 Oct 2014 23:35:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xaz4c-0007DD-Ai for emacs-devel@gnu.org; Sun, 05 Oct 2014 23:35:05 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:35615) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xaz4L-00078M-T0; Sun, 05 Oct 2014 23:34:42 -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 725D91C3939; Mon, 6 Oct 2014 12:34:40 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 644D51A2888; Mon, 6 Oct 2014 12:34:40 +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:175002 Archived-At: Richard Stallman writes: > Given a self-contained Scheme program, it should be easy to determine > whether it ever examines or sets string text properties. Is that enough > to provide the same "security" benefits in practice? No. Often systems are constructed by assembling separately developed modules. If a "security" module responsible for checking data validity is property-oblivious, then maliciously crafted properties may be able to cause "evil" behavior in a property-sensitive module supposedly protected by the "security" module. This kind of problem is often exposed when the "security" module was designed for a Scheme version without some feature (here "string properties"), and the infrastructure is updated to an interpreter version with the feature. You can impugn the skills of the programmers responsible, or say it's all very hypothetical (which I admit, not being a cracker myself I don't know how to turn such configurations into actual exploits), but this is a common pattern for security breaches. It's a great service to the Internet community for the Guile developers to worry about it and at least document the issues faced when using Guile.