Suhail Singh <suhailsingh...@gmail.com> writes: > Ihor Radchenko <yanta...@posteo.net> writes: > >> If you are actively using #+LINK: keywords with %(...) placeholders or >> have any objections to this feature removal, please let us know. > > I do not actively use this feature, however, removing it seems > excessive. IIUC, it's a useful feature in situations when the tag may > require deterministic, yet non-trivial manipulation. The current > mechanism of restricting this to functions marked safe by user seems > sufficient. > > Am I missing something? Is the threat model such that it can only be > adequately addressed by removing the feature altogether?
There are two issues: 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. 2. Making it secure also made it significantly less useful, if it ever was all that useful. For the %(...) specifier to be useful, you need a pure/safe function that takes exactly one string argument and produces the string you need. You can, of course, write that function; but then you might as well use org-link-abbrev-alist instead of defining a local #+LINK. Personally, I'd start by forbidding %(...) placeholders in buffer-local #+LINK: definitions, they're perfectly safe in org-link-abbrev-alist.
