From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Lundin Subject: Re: [ANN] Org-babel integrated into Org-mode Date: Wed, 30 Jun 2010 08:13:51 -0400 Message-ID: <87y6dwn2f4.fsf@fastmail.fm> References: <87wrtp78rg.fsf@gmail.com> <874oglofzs.fsf@fastmail.fm> <87d3v98piu.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from [140.186.70.92] (port=44119 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OTw61-0000nY-2o for emacs-orgmode@gnu.org; Wed, 30 Jun 2010 08:08:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OTw5z-0002gZ-Fd for emacs-orgmode@gnu.org; Wed, 30 Jun 2010 08:08:52 -0400 Received: from out1.smtp.messagingengine.com ([66.111.4.25]:51942) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OTw5z-0002gS-C4 for emacs-orgmode@gnu.org; Wed, 30 Jun 2010 08:08:51 -0400 In-Reply-To: <87d3v98piu.fsf@gmail.com> (Eric Schulte's message of "Tue, 29 Jun 2010 15:03:53 -0700") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Eric Schulte Cc: Org Mode Hi Eric, Thanks so much for taking these observations into account. "Eric Schulte" writes: > Thanks for raising the point about potentially dangerous code blocks. > > Matt Lundin 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" 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. Yes, I can certainly understand this. My own preference is for modularity and minimalism---i.e., if possible, give users the option of *not* loading or requiring a package. For example, I appreciate that org-habit is a module --- one doesn't have to load it if one doesn't want to. But org-habit is perhaps more clearly an "add-on" than is org-babel. Having used the latter only for perl, python, and shell code evaluation, I imagine I underestimate the enhancements it makes to the core functionality of org source blocks. :) >> - 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. > Yes, this is my primary concern. >> >> + 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. Perhaps some combination of 1 and 2? Best, Matt