[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs Lisp's future

From: David Kastrup
Subject: Re: Emacs Lisp's future
Date: Tue, 07 Oct 2014 17:40:43 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

Andreas Schwab <address@hidden> writes:

> Mark H Weaver <address@hidden> writes:
>> However, if the overlong sequence came from the network, and Emacs
>> propagates it unchanged to internal subsystems[*] (e.g. via command-line
>> arguments to subprocesses), that's not good.  It exposes another program
>> to invalid input -- a program that might not be designed for exposure to
>> possible attacks via overlong encodings.
> At least it doesn't make it worse (it is unchanged from the situation if
> you remove Emacs as a filter).

And if Emacs is supposed to be used as a propagate-only-valid-utf-8
filter (which it definitely can do), that should be in the spec and
Emacs should then programmed to do the desired failure mode.

Just bombing out in some predetermined manner in some fixed location is
not a substitute for properly planned behavior.

If you want Emacs (or GUILE, or whatever) to take a particular action in
a particular case in order to provide output with particular guarantees
to particular processing stages, then "somebody thought it was a good
idea" in some inconvenient place is not a substitute.

Unless told differently, a tool like GUILE or Emacs, when used as a
filter, should do exactly _those_ filtering operations you tell it.  Not
more, not less.  Anything else is _guaranteed_ to get in the way

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]