From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eric Schulte" Subject: Re: [ANN] Org-babel integrated into Org-mode Date: Tue, 29 Jun 2010 15:03:53 -0700 Message-ID: <87d3v98piu.fsf@gmail.com> References: <87wrtp78rg.fsf@gmail.com> <874oglofzs.fsf@fastmail.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from [140.186.70.92] (port=33284 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OTiuP-0000pe-Ge for emacs-orgmode@gnu.org; Tue, 29 Jun 2010 18:04:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OTiuN-00084l-Bg for emacs-orgmode@gnu.org; Tue, 29 Jun 2010 18:04:01 -0400 Received: from mail-pv0-f169.google.com ([74.125.83.169]:36376) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OTiuM-00084f-WC for emacs-orgmode@gnu.org; Tue, 29 Jun 2010 18:03:59 -0400 Received: by pvg11 with SMTP id 11so166006pvg.0 for ; Tue, 29 Jun 2010 15:03:58 -0700 (PDT) In-Reply-To: <874oglofzs.fsf@fastmail.fm> (Matt Lundin's message of "Tue, 29 Jun 2010 14:23:03 -0400") 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: Matt Lundin Cc: Org Mode Hi Matt, 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. > > - 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. > > + 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. 3) We package babel as a module, which would need to be explicitly required to be used. > >> 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? > Thanks for catching this, I never run "make install" and it didn't occur to me to think about the installed directory structure for languages. Currently the language-specific files occupy an odd role. They are not compiled or loaded by default because many of them have exotic/complex dependencies which most users will want to avoid -- e.g. slime. For this reason they must be explicitly required by users, and I think for the moment at least would need to be manually installed for a global instillation -- although I suppose we could update the Makefile to begin copying the un-compiled language files into the global lisp tree during instillation. At the same time the language files *are* part of Babel and Org-mode for things like FSF copyright attribution, so they live in the Org-mode lisp tree. > > 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. > Looks like it may be necessary to move ob-* files out of LISPF and into their own new Makefile variable, so they can be handled separately and placed into a babel sub-directory. Hope this make sense, please let me know what you think. Thanks -- Eric > > Thanks! > Matt