Re: per-file (or, really, per buffer) allowing/disallowing code block execution

[Ihor Radchenko <yantar92@gmail.com>]

Fedja Beader <fedja@protonmail.ch> writes:

>> As Tomas pointed out, Emacs has a concept of safe and non-safe
>> file-local variables. org-confirm-babel-evaluate in particular is only
>> safe when it is set to t (query execution). If your downloaded file
>> attempts to set org-confirm-babel-evaluate to nil, Emacs will show a
>> warning and ask you whether you want to use this unsafe nil value.
>
> Can this mechanism be relied upon? I see in
> https://www.gnu.org/software/emacs/manual/html_node/emacs/Safe-File-Variables.html
> that user may press ! to mark everything safe. This is less effort than
> the explicit "yes" required for executing a block on C-c C-c.

While I agree with you, most people appear to prefer a single char. In
fact, it is very popular to replace _all_ the yes/no prompts in Emacs
with y/n prompts.

If you have an interest to change single-char prompt for buffer-local
variables, feel free to file a bug report to Emacs. AFAIK, there is
currently no way to customize this prompt.

>> Note that Org mode already has a large number of customizations, which
>> is why we are trying to not introduce unnecessary customizations. Too
>> many options is not always a good thing.
>
> This makes me wonder how many of us have a custom init.el for
> the purpose discussed here. Surely I am not alone, and surely
> having such customisation maintained in org-mode itself would
> be better.

I personally rarely use org-babel-execute-buffer and thus changed
org-confirm-babel-evaluate to nil + added default export :eval no-export
header arg. Since I run src blocks using C-c C-c, I always see what I am
about to execute.

>> Yes-for-all/No-for-all may be implemented in multiple ways:
>> - During the current org-babel-execute-buffer call
>
> If the user determined that it is safe to execute all blocks
> once, then why would it not be safe to execute them again?

Consider a code in Org file that makes dangerous things. It may be
useful to keep a query about execution just to stop and think for a
moment if you really want to do it. Not for every block in buffer, but
once.

>> - From now until the buffer is closed
>
> This option is probably closest to what I want.
>
>> - Forever for this file path
>
> Also fine. But
> 1) then this would have to be stored somewhere outside
>    of the file, else the user would still be asked if they
>    want to load that unsafe local variable. Meaning that in
>    that case babel could just ask the user directly.
> 2) As I learn to use Emacs, the number of restarts
>    decreases, meaning that the session just lives forever.
>    In that case the once per open nagging of babel
>    is acceptable.

The second option is a bit more consistent with file-local variable
handling and, more importantly, with `org--confirm-resource-safe' - the
approach we use to download remote #+SETUPFILE.

>> - Forever for this file path until the file contents is changed
>
> What would change the file if not the user, and if the user
> already approved the existing code, why would the user
> not approve their own additions to it?
>
>> - For some period of time
>
> Same response as above.

I was mostly thinking about a file being replaced by a new downloaded
version. This is probably an overkill though.

>> Moreover, the above may apply for all the src blocks in buffer or just a
> particular src block.
>
> Going through blocks one by one and whitelisting, then executing them
> seems like a reasonable course of action, so why not.
> However, it might be a bit difficult to implement?
> How would babel determine that a block is the same
> one, even if it changes? Position in file?

We can use the same approach with :cache header argument. However, I
feel that it is also an overkill and will rarely be needed.

>> I doubt that all the options should be implemented in practice. We may
>> probably just allow yes-for-all when running org-babel-execute-buffer
>> but not individual C-c C-c on src blocks. I can see valid reasons to
>> allow (1) in current org-babel-execute-buffer-call; (2) until the buffer
>> is closed; (3) until the file contents is changed + limited by time.
>> However, 3 possible options in the dialogue may be disorienting:
>
> I would like the option to mark whole file as
> trusted without having to execute all blocks in it.

If we use the approach similar to `org--confirm-resource-safe' and
`org-safe-remote-resources', the safe files will be accumulated into a
custom variable. That custom variable can be modified by user just as
any other custom variable.

>> yes/no (each src block)
>> Yes/No (all src blocks in current org-babel-execute-buffer cal)
>
> all/none? always/never?
>
>> * (until the buffer is closed)
>
> allfornow? alluntilclose?
>
>> ! (until the buffer is closed and in the next 30 days, as long as the
>>  buffer contents is not changed)
>
> I'd prefer having to type full words,
> so that it is obvious what the user meant.

I also prefer full words, though it will be slightly inconsistent with
file-local variables and remote resource query in Org.

Summary:

1. We can modify `org-babel-confirm-evaluate' to allow 3 extra answers:
- All (or maybe Yes, consistent with common bash script query)
- None (or maybe No, consistent with common bash script query)
- Always

The new version can be modelled after `org--confirm-resource-safe'.

Never is futile because user executing org-babel-execute-buffer will not
expect the command to be ignored.

Always will not be shown if `org-confirm-babel-evaluate' is not set to
'prompt or 'safe.

2. We can add C-h help buffer detailing what the answers to (similar to
   query-replace prompt)
3. We add a new custom variable org-confirm-babel-evaluate-safe-paths
   that will hold files marked safe.
4. We add two allowed values to `org-confirm-babel-evaluate': 'prompt
   and 'safe, just like in `org-resource-download-policy'. The default
   will be changed to 'prompt
5. We document changes in the manual and in the NEWS.

Patches are welcome!

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92