Re: Thoughts on the standardization of Org

[Tom Gillespie]

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