Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

[吴锐扬]

Hi,

I have org-confirm-babel-evaluate set to t by default. With this, I expect to be queried with the execution of every code block or lob call. However, this does not happen when exporting lob calls (to latex for example). Here is an example:
______________________________________

1. Exporting code block (with evaluation)
#+name: foo
#+begin_src emacs-lisp :exports both
  (message "hello world!")
#+end_src

When exporting this to latex, I get queried as expected. And there is no way to suppress the query unless I change org-confirm-babel-evaluate to nil.

2. Exporting lob call
#+name: foo
#+begin_src emacs-lisp
  (message "hello world!")
#+end_src

#+call: foo()

When exporting this to latex, I don’t get queried. This seems dangerous to me.
______________________________________

I find it hard to explain this inconsistency. If org-confirm-babel-evaluate is designed to be a protective layer, then a user might export an org file that includes malicious code along with a lob call, while unawarely execute that code without being warned. This seems to defeat the purpose of org-confirm-babel-evaluate.

As I searched the archive, I found this change was introduced in the following thread: https://lists.gnu.org/archive/html/emacs-orgmode/2013-04/msg00764.html

+             (let (org-confirm-babel-evaluate)
+               (org-babel-execute-src-block nil info))))))))))

Do you think this is the intended behavior of org-confirm-babel-evaluate, or am I missing something?

Thanks,
Ruiyang

Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

[吴锐扬]

This is just a follow up to see if anyone have insights on this matter. Thanks

Ruiyang

> On Oct 14, 2020, at 1:18 PM, 吴锐扬 <ywwry66@gmail.com> wrote:
> 
> Hi,
> 
> I have org-confirm-babel-evaluate set to t by default. With this, I expect to be queried with the execution of every code block or lob call. However, this does not happen when exporting lob calls (to latex for example). Here is an example:
> ______________________________________
> 
> 1. Exporting code block (with evaluation)
> #+name: foo
> #+begin_src emacs-lisp :exports both
>  (message "hello world!")
> #+end_src
> 
> When exporting this to latex, I get queried as expected. And there is no way to suppress the query unless I change org-confirm-babel-evaluate to nil.
> 
> 2. Exporting lob call
> #+name: foo
> #+begin_src emacs-lisp
>  (message "hello world!")
> #+end_src
> 
> #+call: foo()
> 
> When exporting this to latex, I don’t get queried. This seems dangerous to me.
> ______________________________________
> 
> I find it hard to explain this inconsistency. If org-confirm-babel-evaluate is designed to be a protective layer, then a user might export an org file that includes malicious code along with a lob call, while unawarely execute that code without being warned. This seems to defeat the purpose of org-confirm-babel-evaluate.
> 
> As I searched the archive, I found this change was introduced in the following thread: https://lists.gnu.org/archive/html/emacs-orgmode/2013-04/msg00764.html
> 
> +             (let (org-confirm-babel-evaluate)
> +               (org-babel-execute-src-block nil info))))))))))
> 
> Do you think this is the intended behavior of org-confirm-babel-evaluate, or am I missing something?
> 
> Thanks,
> Ruiyang
> 

Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

[Eric S Fraga]

On Wednesday, 14 Oct 2020 at 16:18, 吴锐扬 wrote:
> I have org-confirm-babel-evaluate set to t by default. With this, I
> expect to be queried with the execution of every code block or lob
> call. However, this does not happen when exporting lob calls (to latex
> for example). Here is an example:

Confirmed with fairly recent org from git with
org-confirm-babel-evaluate set to t.  Does seem a little strange.  It
doesn't bother me much as I don't export org files that I haven't
created myself but it does appear to be a hole.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4-61-ga88806.dirty

Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

[Berry, Charles via General discussions about Org-mode.]

FWIW, it doesn't seem like an accident. You might ping the author of this commit:

$ git log -S "(let (org-confirm-babel-evaluate)"
commit 56bf3d789146fcd3c9f82d875de28c394fe593a0
Author: Achim Gratz <Stromeko@Stromeko.DE>
Date:   Wed Apr 10 20:28:31 2013 +0200

    Babel: avoid superfluous confirmation for internal wrapper
    
    * lisp/ob-exp.el (org-babel-exp-results): Suppress user confirmation
      of the emacs-lisp wrapper execution around a lob call.
    
    * lisp/ob-lob.el (org-babel-lob-execute): Suppress user confirmation
      of the emacs-lisp wrapper execution around a lob call.



HTH,

Chuck

> On Oct 28, 2020, at 4:32 AM, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:
> 
> On Wednesday, 14 Oct 2020 at 16:18, 吴锐扬 wrote:
>> I have org-confirm-babel-evaluate set to t by default. With this, I
>> expect to be queried with the execution of every code block or lob
>> call. However, this does not happen when exporting lob calls (to latex
>> for example). Here is an example:
> 
> Confirmed with fairly recent org from git with
> org-confirm-babel-evaluate set to t.  Does seem a little strange.  It
> doesn't bother me much as I don't export org files that I haven't
> created myself but it does appear to be a hole.
> 
> -- 
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4-61-ga88806.dirty
> 
> 

Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

[吴锐扬]

The author explained his motivation for the commit in the mailing list before it got applied:

> That's because lob calls get wrapped internally in an anonymous
> emacs-lisp source block that then feeds through the result from the
> actual call as elisp.  The attached patch should suppress the
> confirmation for the wrapper call.  To the best of my knowledge nothing
> dangerous can happen with that evaluation and all confirmations for the
> call stack down from there have already taken place according to the
> users' setup.

If I understand correctly, executing a lob call would trigger two user confirmations in the past, and this commit was meant to suppress one of the two confirmations. (I may be wrong since I am a fairly new user of org mode.) Now there is no confirmation at all. IMHO, there should be exactly one confirmation ideally.

But you are right, I should just copy the author on this.

Thanks,
Ruiyang

> On Oct 28, 2020, at 10:26 AM, Berry, Charles <ccberry@health.ucsd.edu> wrote:
> 
> FWIW, it doesn't seem like an accident. You might ping the author of this commit:
> 
> $ git log -S "(let (org-confirm-babel-evaluate)"
> commit 56bf3d789146fcd3c9f82d875de28c394fe593a0
> Author: Achim Gratz <Stromeko@Stromeko.DE>
> Date:   Wed Apr 10 20:28:31 2013 +0200
> 
>    Babel: avoid superfluous confirmation for internal wrapper
> 
>    * lisp/ob-exp.el (org-babel-exp-results): Suppress user confirmation
>      of the emacs-lisp wrapper execution around a lob call.
> 
>    * lisp/ob-lob.el (org-babel-lob-execute): Suppress user confirmation
>      of the emacs-lisp wrapper execution around a lob call.
> 
> 
> 
> HTH,
> 
> Chuck
> 
>> On Oct 28, 2020, at 4:32 AM, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:
>> 
>> On Wednesday, 14 Oct 2020 at 16:18, 吴锐扬 wrote:
>>> I have org-confirm-babel-evaluate set to t by default. With this, I
>>> expect to be queried with the execution of every code block or lob
>>> call. However, this does not happen when exporting lob calls (to latex
>>> for example). Here is an example:
>> 
>> Confirmed with fairly recent org from git with
>> org-confirm-babel-evaluate set to t.  Does seem a little strange.  It
>> doesn't bother me much as I don't export org files that I haven't
>> created myself but it does appear to be a hole.
>> 
>> -- 
>> : Eric S Fraga via Emacs 28.0.50, Org release_9.4-61-ga88806.dirty
>> 
>> 
> 

Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

[Kyle Meyer]

吴锐扬 writes:

> The author explained his motivation for the commit in the mailing list before it got applied:
>
>> That's because lob calls get wrapped internally in an anonymous
>> emacs-lisp source block that then feeds through the result from the
>> actual call as elisp.  The attached patch should suppress the
>> confirmation for the wrapper call.  To the best of my knowledge nothing
>> dangerous can happen with that evaluation and all confirmations for the
>> call stack down from there have already taken place according to the
>> users' setup.

Just for reference: it looks like that's

  https://orgmode.org/list/87k3oaw7jz.fsf@Rainer.invalid

> If I understand correctly, executing a lob call would trigger two user
> confirmations in the past, and this commit was meant to suppress one
> of the two confirmations. (I may be wrong since I am a fairly new user
> of org mode.)

Thanks for digging.  Indeed, if you go back to the parent of 56bf3d789
(Babel: avoid superfluous confirmation for internal wrapper,
2013-04-10), there are two queries.  On that commit, there is one.

> Now there is no confirmation at all. IMHO, there should be exactly
> one confirmation ideally.

It looks like the query went away with dbb375fdf (Simplify Babel calls
evaluation, 2016-06-16), which was included in the 9.0 release.  Based
on a quick glance at that commit, I don't think that was an intentional
change.

I won't take a closer look at this until at least this weekend, though.
I'd be very happy if someone beat me to it.

Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

[Berry, Charles via General discussions about Org-mode.]

Just on a whim, I changed `org-babel-exp-results' by deleting


  (let (org-confirm-babel-evaluate-NOT)

and the matching right parenthesis.

Now I get a single prompt to confirm evaluation using Ruiyang's ECM.

HTH,

Chuck
> On Oct 28, 2020, at 8:16 PM, Kyle Meyer <kyle@kyleam.com> wrote:
> 
> 吴锐扬 writes:
> 
>> The author explained his motivation for the commit in the mailing list before it got applied:
>> 
>>> That's because lob calls get wrapped internally in an anonymous
>>> emacs-lisp source block that then feeds through the result from the
>>> actual call as elisp.  The attached patch should suppress the
>>> confirmation for the wrapper call.  To the best of my knowledge nothing
>>> dangerous can happen with that evaluation and all confirmations for the
>>> call stack down from there have already taken place according to the
>>> users' setup.
> 
> Just for reference: it looks like that's
> 
>  https://urldefense.com/v3/__https://orgmode.org/list/87k3oaw7jz.fsf@Rainer.invalid__;!!LLK065n_VXAQ!29k-PVwb9XnRUW2w0NBea_sA5uaG3P1Ck0lJ_EyddjelOaIrJGxmvvR28RAyZpjHiQ$ 
> 
>> If I understand correctly, executing a lob call would trigger two user
>> confirmations in the past, and this commit was meant to suppress one
>> of the two confirmations. (I may be wrong since I am a fairly new user
>> of org mode.)
> 
> Thanks for digging.  Indeed, if you go back to the parent of 56bf3d789
> (Babel: avoid superfluous confirmation for internal wrapper,
> 2013-04-10), there are two queries.  On that commit, there is one.
> 
>> Now there is no confirmation at all. IMHO, there should be exactly
>> one confirmation ideally.
> 
> It looks like the query went away with dbb375fdf (Simplify Babel calls
> evaluation, 2016-06-16), which was included in the 9.0 release.  Based
> on a quick glance at that commit, I don't think that was an intentional
> change.
> 
> I won't take a closer look at this until at least this weekend, though.
> I'd be very happy if someone beat me to it.

Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

[Kyle Meyer]

Kyle Meyer writes:

> It looks like the query went away with dbb375fdf (Simplify Babel calls
> evaluation, 2016-06-16), which was included in the 9.0 release.  Based
> on a quick glance at that commit, I don't think that was an intentional
> change.
>
> I won't take a closer look at this until at least this weekend, though.
> I'd be very happy if someone beat me to it.

Should be fixed by 20374f69e.  That includes a regression test that will
hopefully prevent an unintended change in either direction (no prompting
or repeat prompting).

Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

[吴锐扬]

Can confirm that. Thanks for your work!

Best,
Ruiyang

> On Nov 1, 2020, at 4:44 PM, Kyle Meyer <kyle@kyleam.com> wrote:
> 
> Kyle Meyer writes:
> 
>> It looks like the query went away with dbb375fdf (Simplify Babel calls
>> evaluation, 2016-06-16), which was included in the 9.0 release.  Based
>> on a quick glance at that commit, I don't think that was an intentional
>> change.
>> 
>> I won't take a closer look at this until at least this weekend, though.
>> I'd be very happy if someone beat me to it.
> 
> Should be fixed by 20374f69e.  That includes a regression test that will
> hopefully prevent an unintended change in either direction (no prompting
> or repeat prompting).

Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

[Achim Gratz]

Berry, Charles" via "General discussions about Org-mode. writes:
> FWIW, it doesn't seem like an accident. You might ping the author of this commit:

No, that change was to suppress an _additional_ confirmation that was
triggered by some internal implementation details.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada