[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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 <address@hidden> 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"


reply via email to

[Prev in Thread] Current Thread [Next in Thread]