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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8160 in the body.
You can then email your comments to 8160 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: MON KEY <monkey <at> sandpframing.com>
To: bug-gnu-emacs <at> gnu.org
Subject: `hack-local-variables-confirm' <-- a confirmed hack!
Date: Wed, 2 Mar 2011 17:37:19 -0500

`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\

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: MON KEY <monkey <at> sandpframing.com>
Cc: 8160 <at> debbugs.gnu.org
Subject: Re: bug#8160: `hack-local-variables-confirm' <-- a confirmed hack!
Date: Sat, 05 Mar 2011 14:46:14 -0500

MON KEY <monkey <at> 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.

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\

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

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: MON KEY <monkey <at> sandpframing.com>
Cc: 8160 <at> debbugs.gnu.org
Subject: Re: `hack-local-variables-confirm' <-- a confirmed hack!
Date: Thu, 14 Jul 2011 20:51:49 +0200

MON KEY <monkey <at> 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/

Previous Next

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