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 <address@hidden> 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.
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.