Re: risky local variable mechanism

[Jonathan Yavner]

Chong Yidong wrote:
> One solution is to to keep `risky-local-variable-p'
> around for unsafep.el to use, but not actually use it in
> files.el---and just rely on the whitelist mechanism.

I don't think this is a good idea.  `risky-local-variable-p' was 
invented five years ago precisely so that files.el and unsafep.el would 
use the same rules for deciding whether variables were safe.  If 
files.el says a variable is unsafe but unsafep.el thinks it's safe, 
that is a security hole (a spreadhseet could be written that would 
tickle the unsafe variable).  If files.el says a variable is safe but 
unsafep says it isn't, that will annoy the user (who will be required 
to approve the use of that variable every time he loads the 
spreadsheet).

In general, lambdas are unsafe if unsafep says they are, so we could 
call it instead of arbitrarily declaring that all xxx-function 
variables are unsafe.  If a variable can be nil, a number, or a lambda, 
we can use unsafep instead of arbitrarily rejecting all lambda cases.


Luc Teirlinck wrote:
> If the current risky-local-variable-p is too unreliable for
> `enable-local-eval' to such a degree that an urgent fix is needed, is
> it really reliable enough for unsafep?

What exactly is the problem with the current system?  Are there unsafe 
variables erroneously declared safe?  Are there file-local variables 
with safe values erroneously declared unsafe?  What is the minimum 
change needed to solve the current problem?


> (risky-local-variable-p myvar nil) very well may return t, even though
> assigning a value of nil may be perfectly safe (and probably is).

Yeah, I don't like that, either.  If a variable has some safe and some 
unsafe values, it seems likely that nil would be one of the safe ones.  
Changing this calling convention would break backward compatibility, 
although it doesn't *seem* like the function is used outside of 
files.el and unsafep.el.


> I am not sure that Chong's patch should use risky-local-variable-p at
> all. 

Again, if files.el and unsafep.el do not use the same mechanism, Emacs 
will have two definitions for the same concept ("safe variable") which 
will lead to either security holes or user annoyance.