Hi Eric, Thanks so much for taking these observations into account.
"Eric Schulte" <schulte.e...@gmail.com> writes: > Thanks for raising the point about potentially dangerous code blocks. > > Matt Lundin <m...@imapmail.org> 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" <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.") > > 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 _______________________________________________ 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
