[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [POLL] We plan to remove #+LINK: ...%(my-function) placeholder from
From: |
Steven Allen |
Subject: |
Re: [POLL] We plan to remove #+LINK: ...%(my-function) placeholder from link abbreviation spec |
Date: |
Fri, 28 Jun 2024 09:20:36 -0700 |
Suhail Singh <suhailsingh247@gmail.com> writes:
> Ihor Radchenko <yantar92@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.
[POLL] Bug of Feature? Attack vector via deceiving link abbrevs (was: [ANN] Emergency bugfix release: Org mode 9.7.5), Ihor Radchenko, 2024/06/28