Re: Re: [ANN] Org-babel integrated into Org-mode

[Carsten Dominik <carsten.dominik@gmail.com>]

On Jun 30, 2010, at 2:53 PM, Matthew Lundin wrote:

> Hi Carsten,
>
> Thanks so much both for thinking this through. And thanks again, Eric,
> for your work in integrating org-babel into org-mode---including  
> taking
> into account a humble user's concerns! :)
>
> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> 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.
>
> I think the default should be t, but I also like giving users the  
> option
> of not loading org-babel.
>
>> 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.
>
> With safeguards with 2, 4, 5, and 6, would it be safe to skip #3 and
> load emacs-lisp evaluation by default? The primary risk right now is
> that C-c C-c is so easy to press. But if we change the keybinding and
> add a default warning, I believe the emacs-lisp evaluation would not
> pose undue dangers.

I agree.


> After all, emacs already makes it easy to evaluate
> emacs-lisp code. IMO, other languages are a bit more dangerous, since
> they are "out of context" in an org-mode document---i.e., one is not
> necessarily as cautious about the pitfalls of executing shell  
> commands,
> perl code, etc. as one is when using the command line or executing a
> script.

Yes.  Emacs Lisp is of course just as dangerous as the shell or
anything else when it comes to malicious intent, but for running
code by mistake it is much less dangerous than the shell,
because usually elisp code deals with stuff inside Emacs
and not so much on the system.

- Carsten