Re: Emacs Lisp's future

[Eli Zaretskii <eliz@gnu.org>]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,
>     dak@gnu.org,
>     mikegerwitz@gnu.org,
>     mhw@netris.org,
>     dmantipov@yandex.ru,
>     emacs-devel@gnu.org,
>     handa@gnu.org,
>     monnier@iro.umontreal.ca
> Date: Mon, 13 Oct 2014 14:35:02 +0900
> 
> (1) The file or application is truly local, provided with the OS or
>     created by the user.  In that case on a well-maintained system,
>     the encoding should be valid, as you pointed out elsewhere.
>     Therefore a strict policy should be transparent.  (See (3) for
>     what I believe to be the main class of exceptions.)
> 
> (2) The file or application was downloaded from the network.  Emacs
>     cannot know the provenance, and so the same care should be taken
>     as with a network stream.
> 
> (3) The application is trustworthy, but produces invalid encoded text
>     in some well-understood situations.  In this case the Lisp program
>     should be allowed to opt out of default validation and provide its
>     own.  Preferably only in the specific situations rather than
>     globally.

There's also the case that the application was invoked on a remote
host, and its output is passed via the network (a.k.a. "Tramp").  Not
sure if those 3 cases cover that.

> An example of (3) is David's case, with AUCTeX handling of TeX error
> messages containing non-unibyte text.)  AFAIK such applications are
> quite rare nowadays.

"Rare" doesn't mean unimportant to users to the degree we can ignore
them.  If we do want to cater to those "rare" cases, the only way of
doing that is maintain a database of programs and their behaviors.  We
don't have that now, and I'm not sure how practical this could be, and
what kind of maintenance burden it would require to keep the database
up to date.

Moreover, I don't think case (1) is as easy as you seem to think.  The
current Emacs policy is to use the locale-specific encoding, but that
is just a heuristic that could easily be false, as modern distributed
network-based computing doesn't lend itself well to the notion of a
fixed locale with a single encoding.  In many cases, a file or a
program that you think are "local" really aren't.

> I understand David and Eli to be of the opinion that in practice there
> is insignificant risk to Emacs or its users from any form of invalid
> or malicious input, from the network or local.  I disagree.

I never said anything like that.  I simply don't have the expertise to
assess the real amount of risk associated with this particular aspect
of Emacs.  All I can cite is my own experience.

What I did say, and stand by, is that doing what you suggest is
certain to cause user outcry of the kind I remember very well.  I
think it's naive to assume that "this time it will be different";
experience has taught me that this attitude is ill-advised.

Therefore, I think Emacs should only go to the kind of strict defaults
you propose if _users_ demand that, or if real-life Emacs use stories
show up that demonstrate the actual danger from using the current
default.  We shouldn't do that out of our own initiative based on
academic considerations and examples from PHP or whatever.