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

["Eric Schulte" <schulte.eric@gmail.com>]

Hi Matt,

Thanks for raising the point about potentially dangerous code blocks.

Matt Lundin <mdl@imapmail.org> writes:

> 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.")
>

I'm less struck by this point, as there are many features of Org-mode
which I personally don't understand or use and I'm certainly some
features the existence of which I am completely unaware.  However as
long as Babel doesn't significantly affect load time, I'd rather it be
present in the background, to simplify it's use.

>
>   - 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 to me is a much more motivating concern.  With arbitrary code
evaluation there is unlimited room for mayhem and destruction (both
malicious and accidental), although anyone who works with code in any
form is already exposed to such risks.

>
>     + 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.).
>

No I don't think it's far fetched at all.  I think any of the three
following solutions (with a strong preference for the first) should
address this problem.

1) My preferred solution would be to keep things largely as they are,
   only w/o emacs-lisp activated by default.  That way there is no
   required configuration change for babel users (aside from having to
   add an 'ob-emacs-lisp require), and we address the issue of
   unintentional code execution -- anyone who has activated a language
   is presumably aware of what they are doing.
   
   Additionally this solution would retain some non-active Babel
   features like tangling.

2) We could add a new global environment variable along the lines of
   org-confirm-shell-link-function, say org-confirm-babel-execution or
   somesuch.  This would be easy to implement, and would retain tangle
   like functionality but doesn't seem as conceptually clean as the
   above solution.

3) We package babel as a module, which would need to be explicitly
   required to be used.

>
>>    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?
>

Thanks for catching this, I never run "make install" and it didn't occur
to me to think about the installed directory structure for languages.

Currently the language-specific files occupy an odd role.  They are not
compiled or loaded by default because many of them have exotic/complex
dependencies which most users will want to avoid -- e.g. slime.  For
this reason they must be explicitly required by users, and I think for
the moment at least would need to be manually installed for a global
instillation -- although I suppose we could update the Makefile to begin
copying the un-compiled language files into the global lisp tree during
instillation.

At the same time the language files *are* part of Babel and Org-mode for
things like FSF copyright attribution, so they live in the Org-mode lisp
tree.

>
> 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.
>

Looks like it may be necessary to move ob-* files out of LISPF and into
their own new Makefile variable, so they can be handled separately and
placed into a babel sub-directory.

Hope this make sense, please let me know what you think.

Thanks -- Eric

>
> Thanks!
> Matt