emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Carsten Dominik
Subject: Re: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Date: Fri, 2 Jul 2010 10:38:48 +0200

Hi Eric,

thanks, I think we have a good solution, at least for the time being.

I have started the security section in the manual, please feel free to add to it.

- Carsten

On Jul 1, 2010, at 4:55 PM, Eric Schulte wrote:

Hi,

Thanks for finding such a good compromises solution.  This new plan
looks great to me, specifics below

Carsten Dominik <address@hidden> writes:

Hi everyone,

first of all, I think it is clear that I may have overreacted
with the "6 point plan".  But it is good that we are having
this discussion.

On Jun 30, 2010, at 6:25 PM, Eric Schulte wrote:

Hi Carsten, Matt, Scott,

Carsten Dominik <address@hidden> writes:

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.


This sounds like a good idea to me, and it should address Matt's
desire
for enabling minimal Org-mode installs.  I would like this to
default to
t, so that new users can try out Org-babel without overmuch effort.

Actually, following Dan's argument, I am paddling back on this one.
Lets just keep it on.

Instead of having a function to unload emacs-lisp, maybe a good way
would be a customize option org-babel-load-languages with a checkbox
for each language, emacs-lisp on by default. This would make it easy fo
people to select the languages they want, without having to add
several require statements to .emacs.


This sounds like a good idea, such a variable would also play the
important role of advertising what languages currently support execution in Babel. One issue with this setup is that I think languages which do
not have FSF attribution (currently only oz) would still require an
explicit `require' statement, however that shouldn't be too surprising
as those statements live in the contrib directory, and users should be
used to having to explicitly require functionality located in contrib.

One nice thing about this setup is that it shouldn't break user's
current config (existing `require' statements will still work).



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.


Sounds good, I think this is a reasonable safety measure.


3. Not loading emacs lisp evaluation by default.


I would push back on this point. Largely because we have now crossed the like to where it is impossible to play with a code block w/o first
dropping down to your configuration files, and evaluating require
statements.


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.


Hmm, I'm less enthusiastic about this point and point 5.  I really
like
how 'C-c C-c' naturally does whatever-I-want given the context in
which
it's called, and I wouldn't want to lose that intuitiveness.
Similarly
'C-c C-o' currently opens the results of a code block, I also find
this
very appealing as it allows for a uniform top-level interface across
an
Org-mode document, be it a code block or a link.

Here are my reasons why I think leaving this keybinding is safe.

1) Unlike with shell/elisp links, the contents of code blocks is
almost
always visible right under the user's point. So it is less likely to
evaluate something w/o having any idea what you are evaluating.

2) Adding a protection variable (e.g. org-confirm-babel-eval) means
that
the only users who could potentially evaluate a code block with a
slip of the fingers would be users who have explicitly said that they
want to be able to easily run code blocks without confirmation.

3) Emacs exposes a number of entry points into code evaluation.  M-!
allows users to run shell commands, C-M-x evaluate the elisp at
point, and these have not caused problems in the past.

These are all very well taken points.  And I agree that a somewhat
regular Org-mode user should be protected by this well enough.

There are actually two kinds of users and two levels where
we need to think about this.

1. I am worried about is this:  Org mode (including Babel)
will soon be part of Emacs an be shipped to a very large number of
people who have nothing to do with Org mode and might pick a file
of the web to try playing with it.  I want to protect these users and
also us, as the Org mode community, from a stupid accident happening
like that. But, in fact, a yes-or-no-p confirmation would probably
cover this well enough. OK for this part.  BTW, Eric,
I think this confirmation variable should also be allowed to take
a function with a two arguments, the language of the snippet
and the snippet.  Users could then write a function which would
get confirmation for some snippets, but not for others.


This sounds like a good idea. I'll update the confirmation function as
you've described.  One possible issue here is that with complicated
setups, a single action could require multiple confirmations -- as
executing one code block can call on other code blocks as arguments, but I think that behavior is required to ensure that the user is fully aware
of the full extent of the processes taking place.


2. The other thing is that I am afraid of myself in this context.
I envision myself turning off the check eval confirmation check sooner
rather than later because I don't like to press the confirmation key
all the time. Repetitive things like this annoy me and I turn them off.
So I am happily working with code in a document fine.

Later, I see myself accidentally pressing C-c C-c in a place where I did not mean to press it. Like in Matt's example, this could be a blog post
or any other document where I have some source code examples.
I press key combinations with C-c *so* many times
a day that a couple of `C-c C-c' come up by accident every day.
In fact, in this context I am more worried about `C-c C-c' than `C-c
C-
o'
This is why I was proposing to not have this in C-c C-c (and, now
you mention it, in C-c C-o) by default.  I definitely think
that it would be good to give users a variable to not include
these into `C-c C-c' and `C-c C-o'.  Having additional bindings
for these two commands in the `C-c C-v' map would not hurt in
any case.

On the other hand, I totally see how C-c C-c is a great and
natural binding if you wan to work with source code, of cause,
and I do understand why you defend it and want to have it in by
default.


Thanks for your understanding on this point.


So in summary, I think I could be fine with a situation
where the variable I just described exists and is set
so that C-c C-c and C-c C-o do the evaluation, and where
the issues are clearly documented.


I see your point, and I think your proposed solution is a good
compromise.  I'll add C-c C-v keybindings for both evaluation and
opening of code blocks. Also, I'll add a variable which can be used to
disable the binding of code block execution to C-c C-c.  We can also
mention this variable in the documentation for the confirmation
variable, so that as users disable block confirmation they will
(hopefully) read the documentation of the variable they are disabling,
and will stop and think "maybe in a world w/o confirmation, I'd feel
safer using a higher friction keybinding".

BTW: any suggestions for C-c C-v key bindings, I'm thinking of the
following, but there may be options with better ergonomics.
| C-c C-v e | for code block execution, mnemonic "execute" |
| C-c C-v o | for opening of results, mnemonic "open"      |

Thanks -- Eric


- Carsten





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.


This sounds like a very good idea. I'd be happy to help write such a
section.


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.


As I mentioned, I personally feel that an org-confirm-babel-eval
variable is sufficient protection.  I think it's safe to assume that
if
a user has explicitly customized that variable, then they know what
they're doing and trust themselves to execute code responsibly.  I
think
it's likely that the casual Org-babel user would never customize this
variable, which seems to me entirely appropriate.


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


So to summarize, I think that the combination of (1), (2) and (6),
should be sufficient to protect users from accidental code evaluation.
Please let me know what you think, I am of course looking to
compromise
and I fully understand that the general consensus may be that we need
more layers of protection.

Best -- Eric


- 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" <address@hidden> 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.
address@hidden
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

- Carsten

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
address@hidden
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

- Carsten

- Carsten






reply via email to

[Prev in Thread] Current Thread [Next in Thread]