Re: Emacs Lisp's future

[Eli Zaretskii <eliz@gnu.org>]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: dak@gnu.org,
>     rms@gnu.org,
>     handa@gnu.org,
>     mhw@netris.org,
>     dmantipov@yandex.ru,
>     emacs-devel@gnu.org,
>     mikegerwitz@gnu.org,
>     monnier@iro.umontreal.ca
> Date: Mon, 13 Oct 2014 17:24:39 +0900
> 
>  > We shouldn't do that out of our own initiative based on academic
>  > considerations and examples from PHP or whatever.
> 
> You think spam, viruses, phishing, buffer overrun exploits, and the
> like are "academic considerations"?

How are these relevant to this discussion (well, except for the
unspecified "and the like" part)?  What do these have to do with text
encoding and decoding in general, and with invalid byte sequences in
particular?  Let's stay focused on the topic at hand, OK?

> They aren't, and the attitude that users can and should take care of
> themselves is *not* a selling point in this environment, except for
> developers who would rather not deal with complex APIs and worse, the
> finicky art of providing convenient, unobtrusive, and yet flexible UI.

All I said was that I want to hear about real-life experiences with
these dangers, where the attackers were able to exploit the Emacs text
decoding machinery to their advantage.  I know it's probably possible
to concoct a synthetic use case for that (although even that was not
done in this thread), but I want to see _real-life_ stories.  Then we
will have specific scenarios to talk about, rather than general
unnamed risks, and also won't need to argue about whether "this can
happen".

Historically, any real-life risks that were reported on the Emacs
lists were handled and fixed very quickly and without any discussions
as to whether they should be fixed.  Rest assured that the same will
happen with the kinds of risks discussed here -- if and when someone
shows us a real-life use case where these risks materialize on our
watch.

We arrived at the current modus operandi of Emacs wrt text encoding
and decoding through sweat, blood, and tears of several major
releases.  It is neither an incident nor luck that complaints about
these issues are rarely if at all seen on the user support forums or
here, for the past 2 major releases.  Changing that in response to
considerations not backed up by specific user reports would be a grave
mistake.  If the history of Emacs development since v20.1 in this area
teaches us anything, it is that we, the Emacs developers, are not good
enough in making these decisions based on theoretical arguments and
considerations.  Suit yourself, but I, for one, don't want us to make
that mistake again, ever.