GNU bug report logs - #8160
`hack-local-variables-confirm' <-- a confirmed hack!

Previous Next

Full log

Message #11 received at 8160 <at> debbugs.gnu.org (full text, mbox):

From: MON KEY <monkey <at> sandpframing.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 8160 <at> debbugs.gnu.org
Subject: Re: 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 <at> 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\

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.