emacs-devel
[Top][All Lists]
Advanced

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

Re: Emacs Lisp's future


From: Stephen J. Turnbull
Subject: Re: Emacs Lisp's future
Date: Sun, 12 Oct 2014 23:49:14 +0900

David Kastrup writes:

 > I don't buy the claims that the ability to faithfully represent
 > arbitrary input in a consistent and reprodusible manner fully supported
 > by all internal operations and kept unconfusable with other characters
 > equals "carelessness in security".

Good for you!  I wouldn't either -- if any such claim had ever been made.

 > Now you claim that you want such support but only if very explicitly
 > requested,

Yes, that is my own preference.  I could easily be wrong for the
general user, as I've been rolling handlers for broken encoding usage
for 25 years.  However, I've also seen the damage that can be done
when a component of a system makes a virtue of transmitting everything
verbatim, and believe it's best to start secure.

 > making it a second-class citizen.

Non-default is *not* second-class.  And if warranted, defaults can be
changed.  I just prefer starting with safe defaults.  Although you
personally may suffer due to the applications you work on, I suspect
you will be surprised at the lack of outcry if you change the default
judiciously, case by case.

 > I've also already given an example of GUILE code that is unable to
 > losslessly pass a string through a string port (the standard
 > mechanism for _accumulating_ a string).

Presumably improving that situation is precisely why Mark is here.

 > Again, this is an outcome of the "let's cater primarily for good
 > encodings" philosophy that is at the bottom of _many_ security
 > problems.

Sigh.  It is *Emacs* that assumes the world is full of valid data, and
happily shovels any hazmat it receives on to the next user or program
without validation.  And you're right, it *is* a security problem.
Not just denial of service, either.  You say that behavior is what
Emacs users want, and maybe it is.  Because most of the time the data
is "nearly" valid and the defects are "insignificant", and hardly a
security problem.  It's the "worse is better" philosophy.[1]

But the rest of the software development world is going in the
opposite direction.  "In God we trust.  All others, present photo ID."
Maybe they have figured something out?  Heck, even Emacs is moving in
the direction of defending *itself* from invalid data in other ways
(thank you, Ted Z!)

Footnotes: 
[1]  Read Gabriel's essay of that title before taking that as an insult.




reply via email to

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