> Actually, for mode-line variables, the situation is a bit more complex:
> the lack of "risky-local-variable" annotation was not introducing any kind
> of security hole because when we interpret a mode-line-string, we discard
> any "dangerous" element (such as "eval") unless the variable is marked as
> "risky".  I.e. either we check its safety via the "risky" annotation or we
> assume it's dangerous and we only use known-safe elements.
> 
> So the "risky" annotation was only added in order to enable potentially
> dangerous things like "eval" in that variable.

We may be speaking at cross-purposes, but are you sure about that?

$ emacs -q lvtest   #lvtest is attached to this message
M-: java-mode-abbrev-table RET
>> cheese
M-: java-mode-syntax-table RET
>> (((nil)))

Both those variables are set sans prompting with the default security
settings; of course, those variables (and the nonsense values I supply)  
are harmless, but other random variables with no `risky' or `safe' 
indications might not be.

I realize now that my example about timeclock is silly, because
`timeclock-mode-string' wasn't dangerous before and isn't now, since it
has never been included in `mode-line-format' except as a symbol, and
those are not evaluated twice (so as to execute a form set as its value).

However, this is itself worthy of note: gm, when he applied the
`risky-local-variable' brand, had mis-diagnosed the danger of that
variable.  All it takes is for one person (whose code, whether part of
Emacs or not, is used widely) to misdiagnose (or forget to diagnose) a
variable in the other direction, and trouble ensues.

So I believe my original statements about the (potential and extreme)
danger of such things -- and the necessity of improvement in their control
-- stand.

Davis Herring

-- 
This product is sold by volume, not by mass.  If it seems too dense or too 
sparse, it means mass-energy conversion has occurred during shipping.