emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Carsten Dominik <carsten.dominik@gmail.com>
To: Matt Lundin <mdl@imapmail.org>
Cc: Org Mode <emacs-orgmode@gnu.org>
Subject: Re: Re: [ANN] Org-babel integrated into Org-mode
Date: Wed, 30 Jun 2010 11:27:37 +0200	[thread overview]
Message-ID: <CF9B7260-39EE-4004-A11B-4324F40301C2@gmail.com> (raw)
In-Reply-To: <874oglofzs.fsf@fastmail.fm>

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.

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.

3. Not loading emacs lisp evaluation by default.

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.

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.

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.

This is what I think - please let me know if you think I am overdoing  
it.

- 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

  parent reply	other threads:[~2010-06-30  9:27 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 [this message]
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
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=CF9B7260-39EE-4004-A11B-4324F40301C2@gmail.com \
    --to=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).