[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: risky local variable mechanism
From: |
Jonathan Yavner |
Subject: |
Re: risky local variable mechanism |
Date: |
Sat, 11 Feb 2006 15:27:31 -0500 |
User-agent: |
KMail/1.6.2 |
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.
Re: Risky local variable mechanism, LENNART BORGMAN, 2006/02/02
re: risky local variable mechanism, Jonathan Yavner, 2006/02/10
- Re: risky local variable mechanism, Luc Teirlinck, 2006/02/10
- Re: risky local variable mechanism, Chong Yidong, 2006/02/11
- Re: risky local variable mechanism,
Jonathan Yavner <=
- Re: risky local variable mechanism, Chong Yidong, 2006/02/11
- Re: risky local variable mechanism, Richard M. Stallman, 2006/02/12
- Re: risky local variable mechanism, Chong Yidong, 2006/02/12
- Re: risky local variable mechanism, Richard M. Stallman, 2006/02/13
- Re: risky local variable mechanism, Chong Yidong, 2006/02/13
Re: risky local variable mechanism, Luc Teirlinck, 2006/02/11
Re: risky local variable mechanism, Richard M. Stallman, 2006/02/12