From: Carsten Dominik <carsten.dominik@gmail.com>
To: Eric Schulte <schulte.eric@gmail.com>
Cc: Matt Lundin <mdl@imapmail.org>, Org Mode <emacs-orgmode@gnu.org>
Subject: Re: Re: [ANN] Org-babel integrated into Org-mode
Date: Fri, 2 Jul 2010 10:38:48 +0200 [thread overview]
Message-ID: <0E3749E7-74E7-4DFB-8252-233FCB8741AA@gmail.com> (raw)
In-Reply-To: <874ogjrzg4.fsf@gmail.com>
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 <carsten.dominik@gmail.com> 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 <carsten.dominik@gmail.com> 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" <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.")
>>>>>
>>>>> - 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
>>
>> - Carsten
- Carsten
next prev parent reply other threads:[~2010-07-02 8:39 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-23 21:09 [ANN] Org-babel integrated into Org-mode Eric Schulte
2010-06-23 23:23 ` Sebastian Rose
2010-06-23 23:41 ` Eric Schulte
2010-06-24 0:03 ` Bernt Hansen
2010-06-24 0:39 ` Eric Schulte
2010-06-24 5:12 ` Nathan Neff
2010-06-24 5:42 ` Eric Schulte
2010-06-24 7:31 ` Sébastien Vauban
2010-06-24 16:27 ` Eric Schulte
2010-06-25 8:28 ` Rainer M Krug
2010-06-25 15:37 ` Eric Schulte
2010-06-26 8:45 ` Štěpán Němec
2010-06-26 15:59 ` Eric Schulte
2010-06-26 16:30 ` Štěpán Němec
2010-06-26 17:27 ` Eric Schulte
2010-06-26 18:45 ` Stephan Schmitt
2010-06-26 19:42 ` Carsten Dominik
2010-06-26 19:51 ` Štěpán Němec
2010-06-28 7:55 ` Rainer M Krug
2010-06-28 11:53 ` Štěpán Němec
2010-06-28 12:16 ` Rainer M Krug
2010-06-28 12:54 ` Bernt Hansen
2010-06-28 13:18 ` Rainer M Krug
2010-06-28 13:25 ` Bernt Hansen
2010-06-28 13:36 ` Rainer M Krug
2010-06-28 16:03 ` Eric Schulte
2010-06-29 7:11 ` Rainer M Krug
2010-06-28 11:32 ` Christopher Witte
2010-06-28 16:59 ` Eric Schulte
2010-07-02 15:50 ` Christopher Witte
2010-06-29 18:23 ` Matt Lundin
2010-06-29 19:08 ` Nick Dokos
2010-06-29 21:01 ` Matt Lundin
2010-06-29 21:27 ` Matthew Lundin
2010-06-29 22:12 ` Nick Dokos
2010-06-29 22:03 ` Eric Schulte
2010-06-29 23:09 ` Eric Schulte
2010-06-29 23:11 ` Eric Schulte
2010-06-30 2:21 ` Nick Dokos
2010-06-30 5:37 ` Eric Schulte
2010-06-30 5:40 ` Eric Schulte
2010-06-30 12:13 ` Matthew Lundin
2010-06-30 9:27 ` Carsten Dominik
2010-06-30 9:59 ` Scot Becker
2010-06-30 12:53 ` Matthew Lundin
2010-06-30 13:24 ` Carsten Dominik
2010-06-30 16:25 ` Eric Schulte
2010-06-30 17:01 ` Dan Davison
2010-06-30 17:17 ` Eric Schulte
2010-06-30 23:08 ` Stephan Schmitt
2010-07-01 0:20 ` Matthew Lundin
2010-07-01 6:27 ` Carsten Dominik
2010-07-01 16:11 ` Nick Dokos
2010-07-01 20:24 ` Sébastien Vauban
2010-07-01 22:14 ` Nick Dokos
2010-06-30 19:41 ` Eric Schulte
2010-07-01 7:20 ` Carsten Dominik
2010-07-01 14:55 ` Eric Schulte
2010-07-01 20:39 ` Eric Schulte
2010-07-01 22:13 ` Christian Moe
2010-07-02 4:22 ` Carsten Dominik
2010-07-02 18:52 ` Eric Schulte
2010-07-02 8:38 ` Carsten Dominik [this message]
2010-06-30 19:01 ` Eric Schulte
2010-06-30 20:47 ` Matthew Lundin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0E3749E7-74E7-4DFB-8252-233FCB8741AA@gmail.com \
--to=carsten.dominik@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=mdl@imapmail.org \
--cc=schulte.eric@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).