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

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

[MON KEY]

`hack-local-variables-confirm' should prompt for an alternative
location to save the safe local variables it "hacks".

As it is now, inadvertently selecting/typing "!" gives
`customize-save-variable' opportunity to trash my otherwise _empty_
custom file.

I don't wish to store large lists of safe-local-variables in either my
`custom-file' or `user-init-file' and have chosen instead to store
these elsewhere esp. where these pertain Common Lisp related
prop-line variables.

There are myriad Common Lisp related variables (current and legacy)
which appear in the prop-line e.g. "Package: FOO;"

The safety of a package name (and Emacs poorly informed consideration
thereof) is simply _NONE_ of Emacs' business!

Moreover, `hack-local-variables-confirm' completely steals focus and
hides my cursor with disgusting abuse around these forms:

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

 (let ((cursor-in-echo-area t)
      (executing-kbd-macro executing-kbd-macro)
      {...}
      (condition-case nil
          (scroll-up)
      (error (goto-char (point-min))))

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*").

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!!!

--
/s_P\

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

[Chong Yidong]

MON KEY <monkey@sandpframing.com> writes:

> The safety of a package name (and Emacs poorly informed consideration
> thereof) is simply _NONE_ of Emacs' business!

If so, (setq enable-local-variables :all) will do the job for you (and
possibly lead to security problems, but it's your call).

> 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.

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\

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

[Lars Magne Ingebrigtsen]

MON KEY <monkey@sandpframing.com> writes:

> `hack-local-variables-confirm' should prompt for an alternative
> location to save the safe local variables it "hacks".
>
> As it is now, inadvertently selecting/typing "!" gives
> `customize-save-variable' opportunity to trash my otherwise _empty_
> custom file.

`customize-save-variable' is how Emacs saves user choices these days, so
I don't think this is a bug.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/