From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Tue, 14 Oct 2014 09:48:35 +0200 Message-ID: <87siirw0q4.fsf@fencepost.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> <83zjd07ce0.fsf@gnu.org> <834mv76udz.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1413273339 15478 80.91.229.3 (14 Oct 2014 07:55:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 14 Oct 2014 07:55:39 +0000 (UTC) Cc: rms@gnu.org, mikegerwitz@gnu.org, mhw@netris.org, dmantipov@yandex.ru, emacs-devel@gnu.org, handa@gnu.org, monnier@iro.umontreal.ca, stephen@xemacs.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 14 09:55:31 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 1Xdwx9-000332-0R for ged-emacs-devel@m.gmane.org; Tue, 14 Oct 2014 09:55:31 +0200 Original-Received: from localhost ([::1]:37110 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xdwx8-0000pT-E4 for ged-emacs-devel@m.gmane.org; Tue, 14 Oct 2014 03:55:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54546) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xdwwr-0000pO-75 for emacs-devel@gnu.org; Tue, 14 Oct 2014 03:55:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xdwwp-0001vZ-WC for emacs-devel@gnu.org; Tue, 14 Oct 2014 03:55:12 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53362) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xdwwp-0001vV-TF for emacs-devel@gnu.org; Tue, 14 Oct 2014 03:55:11 -0400 Original-Received: from localhost ([127.0.0.1]:60532 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xdwwh-0006kx-HH; Tue, 14 Oct 2014 03:55:03 -0400 Original-Received: by lola (Postfix, from userid 1000) id 984D4DF336; Tue, 14 Oct 2014 09:48:35 +0200 (CEST) In-Reply-To: <834mv76udz.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 14 Oct 2014 09:24:40 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:175343 Archived-At: Eli Zaretskii writes: >> Date: Mon, 13 Oct 2014 22:09:37 -0400 >> From: Richard Stallman >> CC: dak@gnu.org, mikegerwitz@gnu.org, mhw@netris.org, >> dmantipov@yandex.ru, emacs-devel@gnu.org, handa@gnu.org, >> monnier@iro.umontreal.ca, stephen@xemacs.org >>=20 >> That distinction is quite blurred in latest Emacs versions. E.g., >> shell-command-to-string might call a process on a remote host and >> communicate with it via open-network-stream or some such. There are >> several interactive commands already that use this feature. >>=20 >> The cases where their arguments for strictness are strongest >> are the noninteractive ones that don't show the text to a user >> for editing. > > I believe the commands that use shell-command-to-string are a good > example of these cases. That function is frequently used as > infrastructure to query an external program about something, and the > result is then used, at least in some cases, to decide how to proceed. And treating undecodable bytes different from other input regarding verification/sanitizing is going to make things more secure just how? I=A0should have thought that using several different mechanisms here is going to increase rather than decrease the number of possible attack vectors. Or is the idea that any application is safe to be called as long as we don't carry more than 200ml of liquids -- sorry, wrong security theatre. --=20 David Kastrup