GNU bug report logs -
#44837
28.0.50; Local-variables: in middle of file wants to get executed
Previous Next
Reported by: Jean Louis <bugs <at> gnu.support>
Date: Tue, 24 Nov 2020 09:56:01 UTC
Severity: minor
Tags: notabug
Found in version 28.0.50
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 44837 in the body.
You can then email your comments to 44837 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44837
; Package
emacs
.
(Tue, 24 Nov 2020 09:56:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Jean Louis <bugs <at> gnu.support>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Tue, 24 Nov 2020 09:56:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
How to reproduce:
- make email with the text containing Local-variables as below.
-------------------- text begin below-----------------------
* Eric S Fraga <e.fraga <at> ucl.ac.uk> [2020-11-24 12:46]:
> On Tuesday, 24 Nov 2020 at 12:00, Jean Louis wrote:
> > Can I automated the execution of Babel code upon opening of the Org
> > file?
>
> You can, by using file local variables. For instance, for some files, I
> do this:
>
> #+begin_src org
> ,* local variables :noexport:
> # Local Variables:
> # eval: (org-sbe "startup")
> # End:
> #+end_src
>
> which will evaluate the named src block "startup" when file is opened.
>
> Note that this is a potential security hole so only do this for files
> you trust!
For me is fine, as I do that for files I create.
When I have opened this email i was also asked to set local variables,
imagine. So that could maybe also mean that one could send email that
is constructed as Org file and if user answers YES, one could inject
malicious stuff.
--------------- the text above -------------------
still asks me if I like to allow eval: (org-sbe "startup")
So I think this is bug in Emacs as Local-variables should be on the
end of the file.
I am asked when editing such email to execute those local variables
above quoted even though they are not on the end of the file. I think
this is security issue as described above in the same file. People
could spam other users, include some local variables and those
answering with Emacs could send them their email addresses, or
passwods or other private information, it could also invoke various
modes like Org mode and execute various scripts.
--
Thanks,
Jean Louis
⎔ λ 🄯 𝍄 𝌡 𝌚
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44837
; Package
emacs
.
(Thu, 26 Nov 2020 05:49:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 44837 <at> debbugs.gnu.org (full text, mbox):
I am proposing following changes to the dialogue with unsafe
variables:
- to include on minibuffer the option ? to READ MANUAL and lead user
to the section 49.2.4.2 Safety of File Variables where there are
dangerous to data cited
- to make the dialogue window with cursor rather than without any
cursor how it is now, so that user can click on buttons pointing to
the above manual page
- to designate some parts as shown below to be buttons to the manual
page clickable both from console and from X Emacs
- to give user option to permanently mark specific file or directory
variables as unsafe and not to be asked again to accept them over
and over again as that makes unfair choice to user
- if user clicks ? or C-g or tries to escape or anything else but Y or
!, then the dialogue should fail and file get loaded just as
usual. Upon the next opening of the file everything should go as
usual.
- to add section in the tutorial that references that variables should
not be opened as nothing about these issues is written in the
tutorial. One could say that before accepting any variables user
shall read the manual section 49.2.4.2 Safety of File Variables, and
until full understanding is achieved user is advised not to accept
such variables.
From the current template:
==========================
The local variables list in /home/data1/protected/x
contains values that may not be safe (*).
Do you want to apply it? You can type
y -- to apply the local variables list.
n -- to ignore the local variables list.
! -- to apply the local variables list, and permanently mark these
values (*) as safe (in the future, they will be set automatically.)
* eval : (when (and (buffer-file-name) (not (file-directory-p (.......
Proposed hyperlinks to manual page:
===================================
The local variables list in /home/data1/protected/x
^^^^^^^^^^^^^^^
contains values that may not be safe (*).
^^^^^^ ^^^^^^^^^^^^^^^^^^^
Do you want to apply it? You can type
y -- to apply the local variables list.
^^^^^^^^^^^^^^^^^^^^^^^^^
n -- to ignore the local variables list.
! -- to apply the local variables list, and permanently mark these
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
values (*) as safe (in the future, they will be set automatically.)
* eval : (when (and (buffer-file-name) (not (file-directory-p (.......
^^^^^^
- to give to user option to permanently NOT mark these values to be
accepted, as the choice above is inclined to accept variables and it
makes users error prone to accept unsafe variables, but it does not
give option to permanently mark those as unsafe.
This is more important for dir local variables where user may be
asked many times to accept variables.
Being asked 20 times will make user finally permanently accept
variables.
But user has no visible way to permanently ignore those variables.
- safety for millions of users who do not use Emacs Lisp or who may
not be programmers.
Reasons:
========
- Emacs assumes wrongly that millions of users will know the meanings
of "variable", "value", "apply" variable, "eval" and "safe",
including the meanings of all of the Emacs Lisp that may be shown
after eval: line and that seem not to be user friendly
- to follow the principle of being self-documenting one shall give
hyperlinks or references to documentation, thus giving user the
actual informed choice.
- right now user does not have informed choice and is coerced to
permanently accept variables.
More references:
https://lists.gnu.org/archive/html/emacs-orgmode/2020-11/msg00609.html
https://lists.gnu.org/archive/html/emacs-orgmode/2020-11/msg00633.html
Here are references of confused users on Stack-something:
https://lists.gnu.org/archive/html/emacs-orgmode/2020-11/msg00655.html
https://lists.gnu.org/archive/html/emacs-orgmode/2020-11/msg00665.html
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44837
; Package
emacs
.
(Thu, 26 Nov 2020 11:16:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 44837 <at> debbugs.gnu.org (full text, mbox):
Jean Louis <bugs <at> gnu.support> writes:
> How to reproduce:
>
> - make email with the text containing Local-variables as below.
[...]
>> #+begin_src org
>> ,* local variables :noexport:
>> # Local Variables:
>> # eval: (org-sbe "startup")
>> # End:
>> #+end_src
>>
>> which will evaluate the named src block "startup" when file is opened.
I'm unable to reproduce this bug. How are you reading this mail?
rmail? Gnus? Something else?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44837
; Package
emacs
.
(Thu, 26 Nov 2020 12:48:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 44837 <at> debbugs.gnu.org (full text, mbox):
* Lars Ingebrigtsen <larsi <at> gnus.org> [2020-11-26 14:15]:
> Jean Louis <bugs <at> gnu.support> writes:
>
> > How to reproduce:
> >
> > - make email with the text containing Local-variables as below.
>
> [...]
>
> >> #+begin_src org
> >> ,* local variables :noexport:
> >> # Local Variables:
> >> # eval: (org-sbe "startup")
> >> # End:
> >> #+end_src
> >>
> >> which will evaluate the named src block "startup" when file is opened.
>
> I'm unable to reproduce this bug. How are you reading this mail?
> rmail? Gnus? Something else?
By invoking emacsclient
That it is email is not relevant. I would like to say that focus shall
be on those follow up emails from me on how to improve the dialogue.
Did you get it?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44837
; Package
emacs
.
(Thu, 26 Nov 2020 12:56:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 44837 <at> debbugs.gnu.org (full text, mbox):
Jean Louis <bugs <at> gnu.support> writes:
>> I'm unable to reproduce this bug. How are you reading this mail?
>> rmail? Gnus? Something else?
>
> By invoking emacsclient
>
> That it is email is not relevant. I would like to say that focus shall
> be on those follow up emails from me on how to improve the dialogue.
>
> Did you get it?
Nope. Having an Emacs client eval arbitrary code that it's receiving
would be a major security problem. Loading local files is less of a
problem.
So if this has nothing to do with emails, that's nice.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44837
; Package
emacs
.
(Fri, 27 Nov 2020 01:02:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 44837 <at> debbugs.gnu.org (full text, mbox):
* Lars Ingebrigtsen <larsi <at> gnus.org> [2020-11-26 15:55]:
> Jean Louis <bugs <at> gnu.support> writes:
>
> >> I'm unable to reproduce this bug. How are you reading this mail?
> >> rmail? Gnus? Something else?
> >
> > By invoking emacsclient
> >
> > That it is email is not relevant. I would like to say that focus shall
> > be on those follow up emails from me on how to improve the dialogue.
> >
> > Did you get it?
>
> Nope. Having an Emacs client eval arbitrary code that it's receiving
> would be a major security problem. Loading local files is less of a
> problem.
Please see here:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44837#8
> So if this has nothing to do with emails, that's nice.
I do not think that major problem is email but more fundamental in how
is that dialogue displayed.
When I read email with Mutt and use Emacs, then local variables want
to get executed.
My comments are on the above link as I forgot to include you and
assumed you would get email automatically.
Thank you,
Jean
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44837
; Package
emacs
.
(Wed, 08 Sep 2021 09:48:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 44837 <at> debbugs.gnu.org (full text, mbox):
Jean Louis <bugs <at> gnu.support> writes:
> When I read email with Mutt and use Emacs, then local variables want
> to get executed.
Just to ensure that I understand you -- this has nothing to do with
reading mail, has it? It's about opening a file containing local
variables in Emacs from disk? (I asked before, but the response was
ambiguous.)
(That you received the file via mail is pretty immaterial.)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Wed, 08 Sep 2021 09:48:02 GMT)
Full text and
rfc822 format available.
Removed tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Thu, 07 Oct 2021 18:08:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44837
; Package
emacs
.
(Mon, 02 May 2022 08:49:02 GMT)
Full text and
rfc822 format available.
Message #30 received at 44837 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Just to ensure that I understand you -- this has nothing to do with
> reading mail, has it? It's about opening a file containing local
> variables in Emacs from disk? (I asked before, but the response was
> ambiguous.)
>
> (That you received the file via mail is pretty immaterial.)
Everything seems to be working as designed here -- Emacs will query you
about local variable stuff, and if you don't want that, then customize
`inhibit-local-variables-regexps' to ignore all the files.
So I'm closing this bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) notabug.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Mon, 02 May 2022 08:49:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
44837 <at> debbugs.gnu.org and Jean Louis <bugs <at> gnu.support>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Mon, 02 May 2022 08:49:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 30 May 2022 11:24:07 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 20 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.