bug#8160: `hack-local-variables-confirm' <-- a confirmed hack!

[MON KEY]

On Sat, Mar 5, 2011 at 2:46 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
>
> If so, (setq enable-local-variables :all) will do the job for you (and
> possibly lead to security problems, but it's your call).
>

What specifically wrt:
 "[Pp]ackage: FOO;"

are the potential security problem(s)?

>> Worst of all is that if I "C-g' inside `hack-local-variables-confirm'
>> it doesn't even bother to clean up after itself with an
>> `unwind-protect' and instead leaves behind the "*Local Variables*"
>> buffer created with (get-buffer-create "*Local Variables*").
>
> This is so that you can go back and look at what the problematic
> variables were.
>

Yes (as acknowledged of the original bug report):

,----
| Presumably this is not an intended feature and is an oversight of
| `hack-local-variables-confirm' because were I to switch into the
| lingering "*Local Variables*" buffer to inspect the offending
| variables I'm not even left with a visible cursor in the buffer!!!
`----

It is understood that this may have been the +intention+ and it falls
short by lacking the follow through to unwind-protect from this:

 (set (make-local-variable 'cursor-type) nil)

There is a certain irony here, in order to protect the user form herself
implementation of this "security" feature requires Emacs completely
stealing focus _and_ all user access to the application top-level by
way of a *local-variable*... one which may itself be left in an "unsafe"
 state.

--
/s_P\