emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Bastien <bzg@gnu.org>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: Tom Gillespie <tgbugs@gmail.com>,  Kyle Meyer <kyle@kyleam.com>,
	emacs-orgmode@gnu.org
Subject: Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable
Date: Fri, 30 Dec 2022 09:52:48 +0100	[thread overview]
Message-ID: <878rips273.fsf@bzg.fr> (raw)
In-Reply-To: <87h6xetbfn.fsf@localhost> (Ihor Radchenko's message of "Thu, 29 Dec 2022 16:35:40 +0000")

Thanks a lot for the detailed answer, very helpful.

> What changed: The prompt previously displayed on code block evaluation
> is now also displayed when expanding header arguments:

I see nothing in etc/ORG-NEWS that describes this change: am I missing
something?

>> Whether it changed or not, what is the problem in 9.6?
>
> The problem is that Org now displays more queries.
>
>> How does the patch solves this problem?
>
> It allows disabling these new queries about lisp evaluation outside
> code blocks without disabling code block eval confirmation completely.

Is there a real use-case for this?  

It looks like the patch fixes the "too many queries" problem by
providing a setup that is similar to what was the previous default
(i.e. only asking about code block evaluation when
org-confirm-babel-evaluate-cell is set to nil.)

But are we sure that users need to confirm header args evaluation
separately from code blocks evaluation?

IOW I have difficulties understanding when these would be relevant:

(setq org-confirm-babel-evaluate-cell nil)
(setq org-confirm-babel-evaluate t)

> I later suggested disabling the queries by default - mimicking the pre
> 9.6 behaviour yet keeping the ability for concerned users enable the
> extra confirmation.

I think that's the best route: providing, optionnally, more, while not
annoying users who don't want more.

> Yes. Ideally, we need to improve the code evaluation query. It should
> allow confirming evaluation in bulk and add some code blocks/files to
> whitelist. Similar to `org--confirm-resource-safe'.

I see, indeed.

> A concern have been expressed that more queries may annoy users and
> drive them towards setting `org-confirm-babel-evaluate' to nil globally.
> Upon doing this, the future more flexible security queries may be not
> used by such users.

The future more flexible security queries will be made visibile enough
so that users currently setting `org-confirm-babel-evaluate' to nil
will *want* to have a look at it.

>> Also, org-confirm-babel-evaluate-table-cell seems more explicit than
>> org-confirm-babel-evaluate-cell.
>
> But it will not be accurate. The query is now displayed upon executing
> `org-babel-read' -- cell refers to Elisp code "cell" here. Not to a
> table cell.

I find "cell" confusing here (as Max said earlier in the thread).  It
either refers to a table cell or, in Elisp jargon, a "cons cell" (or a
"function cell").

What about modifying `org-confirm-babel-evaluate' to allow these values:

- t      : confirm header vars *and* code blocks
- 'code  : confirm code blocks
- 'vars  : confirm vars
- nil    : don't confirm

and set the default value to 'code, while allowing concerned users to
set it to `t' -- until we have a better system for evaluation query.

WDYT?

-- 
 Bastien


  reply	other threads:[~2022-12-30  8:53 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
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 [this message]
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=878rips273.fsf@bzg.fr \
    --to=bzg@gnu.org \
    --cc=emacs-orgmode@gnu.org \
    --cc=kyle@kyleam.com \
    --cc=tgbugs@gmail.com \
    --cc=yantar92@posteo.net \
    /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).