Re: Emacs Lisp's future

[David Kastrup]

Eli Zaretskii <address@hidden> writes:

>> Date: Mon, 13 Oct 2014 22:09:37 -0400
>> From: Richard Stallman <address@hidden>
>> CC: address@hidden, address@hidden, address@hidden,
>>      address@hidden, address@hidden, address@hidden,
>>      address@hidden, address@hidden
>> 
>>     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.
>> 
>> 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 should 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.

-- 
David Kastrup