Re: Emacs Lisp's future

["Stephen J. Turnbull" <stephen@xemacs.org>]

Richard Stallman writes:

 > If you demonstrate that this claim is valid, I will be concerned.

*sigh*  Be unconcerned.  The world is a *lot* more hostile today than
it was in the days when you posted your passwords on the 'net.

 > It would be a pain in the neck if Emacs strings were something
 > different from Guile strings.

Sure.  Security comes at cost.  That's part of why credit cards charge
a minumum of 5% over prime rate, and why people lose hundreds of
millions of dollars a year to Internet scams: somebody didn't want to
pay that cost, so imposed the risk on others.

The risk is almost invisiblly small in a monolithic Emacs, it's true.
But a Guile-based Emacs is no longer monolithic.  It becomes a
component directly connected to a much larger system of Guile modules,
whose purposes and uses the Emacs developers do not know.  Evidently
some leading Emacs developers are unwilling to care at all about those
unknown purposes and use cases.  If I were a Guile maintainer, I would
be concerned about adding features requested by Emacs.

 > If you want to argue that security justifies this pain,

Sorry, no.  If you want to use a Guile maintained by Mark, you're
going to have to convince him that the benefits of having Guile
implement string properties natively (rather than in the Emacs module
running on top of Guile) is worth overriding his justified paranoia.
I'm trying to convince you and other Emacs developers that you're
going to have to be more sympathetic to security if you want to get
such features into Guile.

 > you need to show it is real security and really does a useful job.

I suspect I can't give you a convincing example, because I haven't
studied the Guile modules "at risk", and in any case, most real risks
would require Guile modules that take advantage of text properties (of
which there are obviously none) or an Emacs -> Guile security code ->
Emacs passage, where the second Emacs instance "trusts" the code
because the Guile security code has validated it, but that's not
possible yet either.

However, here are a couple of analogies.  Even a feature as simple as
".." representing the parent directory has been used in disastrous
network breakins.  The danger of ".." is obvious in retrospect, but
the developers of web servers (several) were taken unaware because
they used system calls to traverse paths, and those calls
authomatically implemented "..".  Sensitive user data (such as
password files) was leaked.

Or how about the recent bash lossage?  s-expressions are just Lisp
data, and could be placed in a property.  Older security code that
does not validate properties might pass arbitrary code (because it
doesn't look at it) to a module that expects to receive a symbol,
eval's it, and voila! you're owned, just as any CGI implemented as a
shell script on a host where /bin/sh is a symlink to bash can own you.
Evaluating functions stored in environment variables is not a POSIX sh
feature; if bash's "sh compatibility" mode actually implemented
compatibility, this exploit would be impossible.  AFAIK setting
POSIX_ME_HARDER doesn't help.

So there you are.  That's the best I can do.