* bug#8160: `hack-local-variables-confirm' <-- a confirmed hack!
@ 2011-03-02 22:37 MON KEY
2011-03-05 19:46 ` Chong Yidong
2011-07-14 18:51 ` Lars Magne Ingebrigtsen
0 siblings, 2 replies; 4+ messages in thread
From: MON KEY @ 2011-03-02 22:37 UTC (permalink / raw)
To: 8160
`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\
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#8160: `hack-local-variables-confirm' <-- a confirmed hack!
2011-03-02 22:37 bug#8160: `hack-local-variables-confirm' <-- a confirmed hack! MON KEY
@ 2011-03-05 19:46 ` Chong Yidong
2011-03-06 8:12 ` MON KEY
2011-07-14 18:51 ` Lars Magne Ingebrigtsen
1 sibling, 1 reply; 4+ messages in thread
From: Chong Yidong @ 2011-03-05 19:46 UTC (permalink / raw)
To: MON KEY; +Cc: 8160
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#8160: `hack-local-variables-confirm' <-- a confirmed hack!
2011-03-05 19:46 ` Chong Yidong
@ 2011-03-06 8:12 ` MON KEY
0 siblings, 0 replies; 4+ messages in thread
From: MON KEY @ 2011-03-06 8:12 UTC (permalink / raw)
To: Chong Yidong; +Cc: 8160
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\
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#8160: `hack-local-variables-confirm' <-- a confirmed hack!
2011-03-02 22:37 bug#8160: `hack-local-variables-confirm' <-- a confirmed hack! MON KEY
2011-03-05 19:46 ` Chong Yidong
@ 2011-07-14 18:51 ` Lars Magne Ingebrigtsen
1 sibling, 0 replies; 4+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-07-14 18:51 UTC (permalink / raw)
To: MON KEY; +Cc: 8160
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/
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-07-14 18:51 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-02 22:37 bug#8160: `hack-local-variables-confirm' <-- a confirmed hack! MON KEY
2011-03-05 19:46 ` Chong Yidong
2011-03-06 8:12 ` MON KEY
2011-07-14 18:51 ` Lars Magne Ingebrigtsen
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.