From: "Eric Schulte" <schulte.eric@gmail.com>
To: Carsten Dominik <carsten.dominik@gmail.com>
Cc: Matt Lundin <mdl@imapmail.org>, Org Mode <emacs-orgmode@gnu.org>
Subject: Re: Re: [ANN] Org-babel integrated into Org-mode
Date: Wed, 30 Jun 2010 09:25:39 -0700 [thread overview]
Message-ID: <87sk4432t8.fsf@gmail.com> (raw)
In-Reply-To: <CF9B7260-39EE-4004-A11B-4324F40301C2@gmail.com> (Carsten Dominik's message of "Wed, 30 Jun 2010 11:27:37 +0200")
Hi Carsten, Matt, Scott,
Carsten Dominik <carsten.dominik@gmail.com> writes:
> Hi Matt, hi Eric,
>
> Matt, thanks a lot for bringing this up. This is indeed a very
> important and serious issue. We need to address it. We need to
> step back and reconsider this carefully.
>
> Don't get me wrong, I absolutely think that Org Babel should give
> you enough rope to hang yourself. But we have to make sure that
> this will not happen to a happy and unsuspecting Org mode, or even
> an unsuspecting Emacs user who by chance opens a file with extension
> .org.
>
> I remember very well when first realized that shell links could
> really affect you badly. It scared me.
>
> You main proposal was to make Org Babel an optional module.
> This will not solve the problem fully, I think, because we also
> don't want that people who turn it on automatically commit
> to potentially dangerous operations. There is a lot of good stuff
> in Babel which has nothing to do with code evaluation.
>
> Here is what I propose (several items are similar to what Eric proposes)
>
> 1. A new variable org-turn-on-babel. We can discuss the default.
> If it is nil, org-babel should not be loaded.
> A default of t would be fine with me if we implement other
> measures listed below.
>
This sounds like a good idea to me, and it should address Matt's desire
for enabling minimal Org-mode installs. I would like this to default to
t, so that new users can try out Org-babel without overmuch effort.
>
> 2. As Eric proposes, a variable similar to org-confirm-shell-link-
> function
> This should by default query for confirmation on any org-babel
> code execution, and can be configured to shut up by people who know
> what they are doing.
>
Sounds good, I think this is a reasonable safety measure.
>
> 3. Not loading emacs lisp evaluation by default.
>
I would push back on this point. Largely because we have now crossed
the like to where it is impossible to play with a code block w/o first
dropping down to your configuration files, and evaluating require
statements.
>
> 4. A new key in the babel keymap for org-babel-execute-code-block,
> for example `C-c C-v e'. This should be documented as the default
> key for this operation.
>
Hmm, I'm less enthusiastic about this point and point 5. I really like
how 'C-c C-c' naturally does whatever-I-want given the context in which
it's called, and I wouldn't want to lose that intuitiveness. Similarly
'C-c C-o' currently opens the results of a code block, I also find this
very appealing as it allows for a uniform top-level interface across an
Org-mode document, be it a code block or a link.
Here are my reasons why I think leaving this keybinding is safe.
1) Unlike with shell/elisp links, the contents of code blocks is almost
always visible right under the user's point. So it is less likely to
evaluate something w/o having any idea what you are evaluating.
2) Adding a protection variable (e.g. org-confirm-babel-eval) means that
the only users who could potentially evaluate a code block with a
slip of the fingers would be users who have explicitly said that they
want to be able to easily run code blocks without confirmation.
3) Emacs exposes a number of entry points into code evaluation. M-!
allows users to run shell commands, C-M-x evaluate the elisp at
point, and these have not caused problems in the past.
>
> 5. Removing org-babel-execute-code-block from `C-c C-c'. Inclusion
> should be optional.
>
> 6. A section in the manual on code execution and associated security
> risks in Org mode. This is not only about babel, but also about
> org-eval, org-eval-light, shell links and elisp links. I have meant
> to write this section for a long time and would be willing to
> draft it. We could then refer to this section from a couple of
> places in the docs, without cluttering the docs with disclaimers.
>
This sounds like a very good idea. I'd be happy to help write such a
section.
>
> The reason for 4 and 5 is that I believe Org-mode users are trained
> to blindly press `C-c C-c' whenever they want to update something at
> point. Matt's example of a blog post about `rm -rf' is a very
> realistic example for bad code being evaluated by mistake, not even
> due to malicious cations. I belive that a special key for this
> action would gove a good measure of protection.
>
As I mentioned, I personally feel that an org-confirm-babel-eval
variable is sufficient protection. I think it's safe to assume that if
a user has explicitly customized that variable, then they know what
they're doing and trust themselves to execute code responsibly. I think
it's likely that the casual Org-babel user would never customize this
variable, which seems to me entirely appropriate.
>
> This is what I think - please let me know if you think I am overdoing
> it.
>
So to summarize, I think that the combination of (1), (2) and (6),
should be sufficient to protect users from accidental code evaluation.
Please let me know what you think, I am of course looking to compromise
and I fully understand that the general consensus may be that we need
more layers of protection.
Best -- Eric
>
> - Carsten
>
>
> On Jun 29, 2010, at 8:23 PM, Matt Lundin wrote:
>
>> Hi Eric,
>>
>> Thanks again for all the work that you, Dan, and Tom have put into
>> org-babel. I'm glad to see it become part of org-mode!
>>
>> "Eric Schulte" <schulte.eric@gmail.com> writes:
>>
>>> 2) Babel will now be loaded by default along with the rest of Org-
>>> mode.
>>> This means that *everyone* currently using babel will need to
>>> change
>>> their Emacs config and remove the (require 'org-babel-int) and/or
>>> (require 'org-babel) lines.
>>
>> I would like to request that org-babel be made an optional module. I
>> ask
>> this as someone who uses org-babel regularly. Here are my reasons:
>>
>> - Org-babel adds rather specific and complex functionality to org-
>> mode
>> that those who use it as a simple outliner and todo manager do not
>> require. (In other words, an option to turn it off might be nice
>> for
>> those who are worried about "feature creep.")
>>
>> - Org-babel increases the risk of accidentally executing malicious or
>> dangerous code when typing C-c C-c on a src block or exporting a
>> file. Perhaps users should activate it only after they understand
>> the risks.
>>
>> + For instance, I might write a blog post warning about the dangers
>> of typing "rm -rf ~/". If I put this between #+begin_src sh
>> and #+end_src and unthinkingly hit C-c C-c, I would be in
>> trouble.
>> I believe this is the reason for the variables
>> org-confirm-shell-link-function and
>> org-confirm-elisp-link-function.
>>
>> + This is admitted a bit far-fetched as an example, as it would
>> require one to have loaded ob-sh.el. But since elisp execution is
>> activated by default, there remain opportunities for unwittingly
>> executing code that is meant for other purposes (e.g., warnings,
>> examples, etc.).
>>
>>> Support for evaluating emacs-lisp code blocks is loaded by default.
>>> All other languages will need to be required explicitly. To
>>> conform
>>> to Emacs filename specifications all language require lines have
>>> been
>>> shortened from e.g.
>>>
>>> (require 'org-babel-sh)
>>>
>>> to
>>>
>>> (require 'ob-sh)
>>
>> When I run make clean && make && make install I find that the language
>> directory is not installed. Does the langs directory require a manual
>> installation?
>>
>> Also, with make install, the ob-* files are installed on the same
>> level
>> as the org-files, yet lines 108-114 in org.el indicate that they
>> should
>> be installed in a babel subdirectory.
>>
>> Thanks!
>> Matt
>>
>> _______________________________________________
>> Emacs-orgmode mailing list
>> Please use `Reply All' to send replies to the list.
>> Emacs-orgmode@gnu.org
>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>
> - Carsten
next prev parent reply other threads:[~2010-06-30 16:26 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-23 21:09 [ANN] Org-babel integrated into Org-mode Eric Schulte
2010-06-23 23:23 ` Sebastian Rose
2010-06-23 23:41 ` Eric Schulte
2010-06-24 0:03 ` Bernt Hansen
2010-06-24 0:39 ` Eric Schulte
2010-06-24 5:12 ` Nathan Neff
2010-06-24 5:42 ` Eric Schulte
2010-06-24 7:31 ` Sébastien Vauban
2010-06-24 16:27 ` Eric Schulte
2010-06-25 8:28 ` Rainer M Krug
2010-06-25 15:37 ` Eric Schulte
2010-06-26 8:45 ` Štěpán Němec
2010-06-26 15:59 ` Eric Schulte
2010-06-26 16:30 ` Štěpán Němec
2010-06-26 17:27 ` Eric Schulte
2010-06-26 18:45 ` Stephan Schmitt
2010-06-26 19:42 ` Carsten Dominik
2010-06-26 19:51 ` Štěpán Němec
2010-06-28 7:55 ` Rainer M Krug
2010-06-28 11:53 ` Štěpán Němec
2010-06-28 12:16 ` Rainer M Krug
2010-06-28 12:54 ` Bernt Hansen
2010-06-28 13:18 ` Rainer M Krug
2010-06-28 13:25 ` Bernt Hansen
2010-06-28 13:36 ` Rainer M Krug
2010-06-28 16:03 ` Eric Schulte
2010-06-29 7:11 ` Rainer M Krug
2010-06-28 11:32 ` Christopher Witte
2010-06-28 16:59 ` Eric Schulte
2010-07-02 15:50 ` Christopher Witte
2010-06-29 18:23 ` Matt Lundin
2010-06-29 19:08 ` Nick Dokos
2010-06-29 21:01 ` Matt Lundin
2010-06-29 21:27 ` Matthew Lundin
2010-06-29 22:12 ` Nick Dokos
2010-06-29 22:03 ` Eric Schulte
2010-06-29 23:09 ` Eric Schulte
2010-06-29 23:11 ` Eric Schulte
2010-06-30 2:21 ` Nick Dokos
2010-06-30 5:37 ` Eric Schulte
2010-06-30 5:40 ` Eric Schulte
2010-06-30 12:13 ` Matthew Lundin
2010-06-30 9:27 ` Carsten Dominik
2010-06-30 9:59 ` Scot Becker
2010-06-30 12:53 ` Matthew Lundin
2010-06-30 13:24 ` Carsten Dominik
2010-06-30 16:25 ` Eric Schulte [this message]
2010-06-30 17:01 ` Dan Davison
2010-06-30 17:17 ` Eric Schulte
2010-06-30 23:08 ` Stephan Schmitt
2010-07-01 0:20 ` Matthew Lundin
2010-07-01 6:27 ` Carsten Dominik
2010-07-01 16:11 ` Nick Dokos
2010-07-01 20:24 ` Sébastien Vauban
2010-07-01 22:14 ` Nick Dokos
2010-06-30 19:41 ` Eric Schulte
2010-07-01 7:20 ` Carsten Dominik
2010-07-01 14:55 ` Eric Schulte
2010-07-01 20:39 ` Eric Schulte
2010-07-01 22:13 ` Christian Moe
2010-07-02 4:22 ` Carsten Dominik
2010-07-02 18:52 ` Eric Schulte
2010-07-02 8:38 ` Carsten Dominik
2010-06-30 19:01 ` Eric Schulte
2010-06-30 20:47 ` Matthew Lundin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sk4432t8.fsf@gmail.com \
--to=schulte.eric@gmail.com \
--cc=carsten.dominik@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=mdl@imapmail.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).