[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#8160: `hack-local-variables-confirm' <-- a confirmed hack!
From: |
MON KEY |
Subject: |
bug#8160: `hack-local-variables-confirm' <-- a confirmed hack! |
Date: |
Sun, 6 Mar 2011 03:12:05 -0500 |
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\