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.e...@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
_______________________________________________
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
