Suhail Singh <suhailsingh...@gmail.com> writes: > Steven Allen <ste...@stebalien.com> writes: > >> 1. While this feature no longer invokes completely arbitrary code, it >> still allows an attacker to call any function marked as "pure" which >> is a pretty large attack surface. > > I am struggling to assess this, because it's not clear to me what the > threat model is. Could you please elaborate? How are the attacker and > potential victim interacting; what is the attack vector(s); who are the > threat agents and what is their goal that we are trying to guard > against, etc?
Scenario: Attacker sends an email containing an inline org-mode part with a malicious link abbreviation. The concern is that, e.g., there may b a function _marked_ as pure that's not actually pure, leaks some information, and/or has a security vulnerability (e.g., a C function exposed to lisp that's marked as pure but internally has, e.g., a buffer overflow). Of course, the actual attack hypothetical. The question being asked here is: is the %(..) specifier in link abbreviations useful enough to warent the potential risks. >> You can, of course, write that function; but then you might as well >> use org-link-abbrev-alist instead of defining a local #+LINK. > > Perhaps I misunderstood, I thought the thing being polled was whether or > not to allow org-link-abbrev-alist to have REPLACE (per its docstring) > be a function. I.e., if %(my-function) is removed, so too would the > ability to have a function in the REPLACE position in > org-link-abbrev-alist. Did I misunderstand? The question is whether or not %(function) placeholders should be allowed in #+LINK: lines. It doesn't actually say anything about allowing them in the global org-link-abbrev-alist. But to be explicit, there are three options: 1. Allow them in both #+LINK: lines and the global org-link-abbrev-alist. 2. Allow them in org-link-abbrev-alist only. 3. Remove them entirely.
