Re: [PATCH] allow function values for `enable-local-eval'

[Karl Fogel]

Richard Stallman <address@hidden> writes:
> That is a general basis for a solution, but it has no specific
> knowledge; it requires that to be provided by the user.  I'm not
> necessarily rejecting it, but it would be more helpful to do something
> that embody specific knowledge, and does the right thing (for some
> cases) without requiring user customization.

Yeah, we could provide such functionality if we can think of it, but I
think it's still necessary to offer the general solution.

It's precisely *because* providing such procedures is non-trivial that
Emacs itself usually won't be able to provide a useful one.  Emacs
doesn't know anything about the user's environment and security
constraints; it doesn't know anything about the particular eval's the
user is looking to allow.

The whole point of the status quo -- that is, the interactive query
when enable-local-eval is set to non-nil, non-t -- is that the user
gets to decide whether or not to eval the code in question.  If we now
give the user the ability to hand that decision off to an arbitrary
procedure, the purpose is merely to enable them to avoid the
interactivity burden where possible, not to avoid the decision itself.
(Naturally, whenever a procedure can't decide, it's free to invoke
y-or-n-p itself.  In fact, my first such procedure does exactly that.)

If we can come up with generally useful decision procedures, we can
certainly include them with Emacs, and plug them into
enable-local-eval using this new mechanism.  But I think it's still
important to offer the general solution, because it is simply not
possible to predict all the ways in which people might want to embody
their security verification methods in code.

For example:

What if you want to automatically eval only expressions that have been
cryptographically signed by someone you trust?  Emacs is not in a
position to implement this in a fully general way right now.  Crypto
programming is difficult and error prone, and we'd have to get into
standards setting and all that.  Whereas by at least providing a
mechanism, we can let solutions evolve as people need them.  (Some of
this code may be contributed back to Emacs, but only if we give people
a chance to write it first.)

Hmmm... and let's remember also that if Emacs provides such
general-purpose procedures, it would also be providing an obvious
target for virus writers to aim at.  Yikes.  We'd have to carefully
vet such procedures.  User-provided procedures have two advantages in
this regard: a) only that one user is vulnerable, instead of the many
users who might use a procedure distributed with Emacs, and b) the
user has only themselves to blame :-).

> Can you show me some of them?  Maybe we can simply allow these forms
> just as the existing code already allows certain `put' expressions.

Yes, they all look roughly like this:

   /* 
    * local variables:
    * eval: (load-file "../../tools/dev/svn-dev.el")
    * end:
    */

(I'm aware that for this particular use-case, there are solutions
available that do not involve enable-local-eval at all, but they have
their own complications, so we chose this way.)

-Karl