This is a great sub-thread that should probably be its own top level thread on org security.
Org files are mostly benign unless the user does something extremely dangerous like setting enable-local-eval t. However, there are some areas where arbitrary code can be executed (as intended) that some users may not be aware of. Consider the following. #+begin_src elisp :var lol=(message "If I were evil I could use call-process here to give you nasal demons") #+end_src When is the closure for the variable lol evaluated? The most obvious time is if you run the block. The less obvious time is if you run org export! More subtly. #+name: some-block #+begin_src elisp #+end_src #+call: some-block() :var pwnd=(message "oops!") When will the closure for pwnd be called? When exporting it happens before you receive the prompt asking whether you want to execute some-block! Very easy to fool someone who doesn't know how top level closures work into goofing on that one. Furthermore even when a file also sets #+property: header-args :eval no-export then the closure will still be evaluated! Or how about Running org export can execute arbitrary code even if you decline to run blocks or set default header-args in your config. This means that it is not safe to, for example, run a public server that transforms arbitrary org files into pdfs. How about some more fun? #+name: some-block #+begin_src elisp :tangle ./itsatrap.el :dir (message "OH NO") #+end_src Yep. That does what you think it does. If you tangle the file, arbitrary code execution. No tangling files from strangers either. The examples I present here do require user input to fire off the process, it won't happen without them doing something but it is much easier to C-c C-e h h or C-c C-v t when you are an expert user, so you have to be careful. Sharp tools. Despite these examples, the ability to define values using arbitrary closures is one of Org's most powerful features. In the context of standardization, this suggests that it might be nice to have a dynamic variable that controls whether bare closures will be evaluated (one might already exist, I have no idea), along with a spec that says what the failure modes should be if one is encountered that cannot be evaluated. In the context of org generally, maybe that variable could also be used like org-confirm-babel-evaluate and take a function as an argument, ask if t, don't ask if nil, or ask only if result is t (or was it nil ... regardless match org-confirm-babel-evaluate). org-confirm-closure-evaluate maybe? (Again if this already exists, then woo!). Best! Tom