emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tom Gillespie <tgbugs@gmail.com>
To: Max Nikulin <manikulin@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable
Date: Tue, 13 Dec 2022 13:16:13 -0800	[thread overview]
Message-ID: <CA+G3_PN+fiEAbPvCp9virsqOK-F0utSoypSpVtksySOrqTvVnw@mail.gmail.com> (raw)
In-Reply-To: <tna9dn$2c9$1@ciao.gmane.io>

> Will it be clear to users what "cell" means in this context?

I assume the language was originally chosen
with tables in mind, but I think it is clear? The
one issue is that using org-babel-confirm-evaluate
doesn't use the word "cell" in the yes-or-no-p prompt.

> Am I wrong that, roughly speaking, the effective value is (and
> org-confirm-babel-evaluate-cell org-confirm-babel-evaluate)?

You are correct. Only in the case that
org-confirm-babel-evaluate-cell is or evaluates to t will
the yes-or-no-p be displayed _IF_ org-confirm-babel-evaluate
is or evaluates to t. org-babel-confirm-evaluate (NOT
org-confirm-babel-evaluate) is the function that issues
the yes-or-no-p.

> Should it be described in the docstring?

Maybe? In the current implementation the value of
org-confirm-babel-evaluate takes precedence, which
I think is the correct behavior. If someone has told
us that they blindly want to execute all code, but
not cells, we should not change the default behavior,
and thus we should execute all cells and blocks

> It seems e.g. :eval query affects the latter, but not the former.

:eval has no impact on cells. In fact in some files I use
:eval (and this-file-done-loading "never") on some blocks that
(setq this-file-done-loading) at the end to achieve only-once
behavior.

> If it is so then it is too complicated for me to feel firm ground
> while reasoning on security.

:eval has never, and cannot impact evaluation of cells, because
it is specifically used to control evaluation of blocks. Similarly
:eval has no interaction with any of the confirm-babel-evaluate
machinery.

I see one possible point of confusion which is that he :eval that
you see in the code of org-babel-read is a hack to create fake
info for a cell.

Are you maybe looking for a file level :eval-cell option/property
that would allow you to declare that you should NEVER run
cells at all and also never prompt? Basically this is an option
that says "treat all cells as if they and their header property
are the default value".

I'm fairly certain that implementing such a thing is a bad
idea, for example if someone sets :dir using a cell and
it is overwritten they could execute code in the wrong
environment, which can lead to nasty security issues.
Thus the only global option for cells that we could safely
implement would have the semantics of "treat all cells
as if they are (error)".

> I have not decided if it is feasible to add some property to the INFO
> argument passed to `org-babel-confirm-evaluate' and to put there
> condition which variable should determine result.

Having done so before, I would rather not touch
org-babel-confirm-evaluate if at all possible. The only
disadvantage is that for now when users are prompted
they will not be informed that it is a cell, however from
the short nature of cells the will hopefully be able to
figure it out.

The fact that org already jumps to the location of
the cell in the file helps a lot with this. Obviously
this doesn't help in a batch context, but if a user
is hitting this in batch mode they are in trouble
anyway.


  reply	other threads:[~2022-12-13 21:17 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-10 20:28 [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable Tom Gillespie
2022-12-11  2:58 ` Max Nikulin
2022-12-11 20:27   ` Tom Gillespie
2022-12-11 20:37     ` Tom Gillespie
2022-12-11 20:46     ` Kyle Meyer
2022-12-11 21:08       ` Tom Gillespie
2022-12-12 10:20         ` Ihor Radchenko
2022-12-13  1:53           ` Tom Gillespie
2022-12-13  9:03             ` Ihor Radchenko
2022-12-13 16:31             ` Max Nikulin
2022-12-13 21:16               ` Tom Gillespie [this message]
2022-12-14 16:40                 ` Max Nikulin
2022-12-14 18:24                   ` Tom Gillespie
2022-12-15  9:18                     ` Ihor Radchenko
2022-12-15  9:25                       ` Tom Gillespie
2022-12-15  9:57                       ` tomas
2022-12-15  9:10                   ` Ihor Radchenko
2022-12-15 12:10                     ` Max Nikulin
2022-12-15 12:25                       ` Ihor Radchenko
2022-12-15 14:46                         ` Max Nikulin
2022-12-15 21:08                           ` Tim Cross
2022-12-16  6:07                             ` Ihor Radchenko
2022-12-16  7:22                               ` Tim Cross
2022-12-18 14:19                                 ` Ihor Radchenko
2022-12-18 21:37                                   ` Tim Cross
2022-12-20  0:00                                     ` Tom Gillespie
2022-12-20  0:06                                       ` Tom Gillespie
2022-12-25 11:00                                         ` Ihor Radchenko
2022-12-18 14:12                           ` Ihor Radchenko
2022-12-25 11:06             ` Ihor Radchenko
2022-12-29 15:58               ` Bastien Guerry
2022-12-29 16:33                 ` Max Nikulin
2022-12-29 16:35                 ` Ihor Radchenko
2022-12-30  8:52                   ` Bastien
2022-12-30 11:10                     ` Max Nikulin
2022-12-30 17:43                     ` Tom Gillespie
2022-12-31 13:48                       ` Ihor Radchenko
2022-12-31 16:15                         ` Tom Gillespie
2023-01-02  8:34                         ` [SECURITY] Arbitrary code evaluation security in Org (was: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable) Ihor Radchenko
2023-01-02 10:59                           ` [SECURITY] Arbitrary code evaluation security in Org Greg Minshall
2023-01-03  9:52                             ` [SECURITY] Tangling can overwrite arbitrary tangling targets, including important user files (was: [SECURITY] Arbitrary code evaluation security in Org) Ihor Radchenko
2023-01-02 19:00                           ` [SECURITY] Arbitrary code evaluation security in Org (was: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable) Tim Cross
2023-01-03 11:00                             ` Ihor Radchenko
2023-01-07 13:12                               ` Ihor Radchenko
2023-01-02 15:13                         ` [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable Bastien Guerry
2023-01-02 15:17                           ` Ihor Radchenko
2023-01-02 15:15                       ` Bastien
2022-12-13  4:16           ` Kyle Meyer
2022-12-13 16:15     ` Max Nikulin

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

  List information: https://www.orgmode.org/

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

  git send-email \
    --in-reply-to=CA+G3_PN+fiEAbPvCp9virsqOK-F0utSoypSpVtksySOrqTvVnw@mail.gmail.com \
    --to=tgbugs@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=manikulin@gmail.com \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).