all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@gmail.com>
To: Fedja Beader <fedja@protonmail.ch>
Cc: "emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>
Subject: Re: per-file (or, really, per buffer) allowing/disallowing code block execution
Date: Sun, 11 Sep 2022 17:10:06 +0800	[thread overview]
Message-ID: <8735cyxonl.fsf@localhost> (raw)
In-Reply-To: <CMF3FCXyBgscotfCMFy5598OTDjGOklEyvUQPLPnAhmmck2mol1rFymeeGTBf1L4PBRS2H6yA_puREavAGZh5eSKDniYDjFq4Bya7g1_bYg=@protonmail.ch>

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


  reply	other threads:[~2022-09-11  9:11 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-05 23:50 per-file (or, really, per buffer) allowing/disallowing code block execution Fedja Beader
2022-09-06 13:33 ` Ihor Radchenko
2022-09-06 19:05 ` Greg Minshall
2022-09-07  0:17   ` Steven Harris
2022-09-07  8:49     ` Greg Minshall
2022-09-08  5:53   ` Ihor Radchenko
2022-09-08 12:34     ` Fedja Beader
2022-09-08 17:41       ` tomas
2022-09-09  5:50       ` Ihor Radchenko
2022-09-10  0:19         ` Fedja Beader
2022-09-11  9:10           ` Ihor Radchenko [this message]
2022-09-12 13:56             ` Greg Minshall
2022-09-12 20:38               ` Tim Cross
2022-09-13  4:47                 ` Greg Minshall
2022-09-19 18:25               ` Rudolf Adamkovič
2022-09-19 19:28                 ` Greg Minshall
2022-09-21 20:56                   ` Rudolf Adamkovič
2022-09-22 14:17                     ` Max Nikulin
2022-09-23  2:31                       ` Ihor Radchenko
2022-09-19  9:23             ` Fraga, Eric

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8735cyxonl.fsf@localhost \
    --to=yantar92@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=fedja@protonmail.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.