emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable


From: Tim Cross
Subject: Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable
Date: Fri, 16 Dec 2022 08:08:28 +1100
User-agent: mu4e 1.9.7; emacs 29.0.60

Max Nikulin <manikulin@gmail.com> writes:

> On 15/12/2022 19:25, Ihor Radchenko wrote:
>> Max Nikulin writes:
>> 
>>> I would consider reverting the commit causing user prompt for every
>>> variable.
>> I disagree. If anything, we can set the default value of
>> `org-confirm-babel-evaluate-cell' to nil and apply this patch.
>> Then, we can get the old behaviour back yet allowing concerned users to
>> have more security.
>
> I am leaving it up to you. Form my point of view it will be dead code that 
> increases
> complexity with no practical outcome. Unfortunately setting
> `org-confirm-babel-evaluate-cell' to anything other than nil results in 
> annoyance rather
> than security.
>
> Perhaps advising `org-babel-execute-src-block' with `y-or-n-p' is a better 
> treatment for
> my paranoia.
>
>> This patch does not only affect src blocks. It affects all the users of
>> `org-babel-read'.
>
> Mostly it is called with INHIBIT-LISP-EVAL set to t.
>
>>> https://list.orgmode.org/Y1uFDWOjZb85lk+3@protected.localdomain
>>> Re: [BUG][Security] begin_src :var evaluated before the prompt to
>>> confirm execution
>> How is it related to the current discussion?
>> The purpose of the security feature discussed here is not for web
>> browsers or anything like that.
>
> I am not going to add malicious source blocks to my private org files. For 
> some code it is
> better to have a prompt, but generally the issue is not excessively 
> important. I tend to
> inspect org files fetched from net in some other application at first 
> (browser, less, or
> vim).
>

While I would argue that is a good practice, it isn't always practicable
for all users. For example, Emacs together with Emacspeak is my primary
accessible interface. While I could use a browser, it would be severely
inconvenient and frustrating.

I have to admit I also have some concerns here. These may or may not be
well founded. My biggest concern is that we don't seem to have a clear
security model. It feels like we are responding to security threats in a
piecemeal and reactive manner and without any clear model. As a result,
there is a risk we will end up with a complex solution where we don't
fully understand how all the separate pieces interact. This could result
in a complex configuration with a low level of confidence, two of
the worst attributes to have when it comes to security.




> Accidental evaluation of code is a real danger for those who insist on 
> opening links to
> org file directly in emacs or even propose to use org as a kind of browser. I 
> raised the
> security issue in response to passionate messages demanding direct ways to 
> work with org
> files from the web. I decided to remind the context with hope that it would 
> help to
> reevaluate severity of the issue.
>

My concern here is that given the power of link configuration, source
blocks, local variables, .dir-local, evaluated block header code etc, it
is extremely difficult to actually know when code will be executed.

One thing I do feel is a risk is that if we don't get the right balance,
the questions about code evaluation may fall to the level of annoying
noise which people get rid of by simply enabling all code evaluation
without question. Obviously, this would be a very bad security decision,
but as we know from years of experience, users will frequently
prioritise convenience over security. If they are unnecessarily 'nagged'
regarding code evaluation, I suspect this is what will happen (noting
that unnecessary is very subjective). 

> I do not have a better proposal, but I think I see movement in a wrong 
> direction.

I'm not sure if I have a better proposal either. I'm not even sure if
this is solely an org issue. It could be that Emacs itself needs a
clearer or better understood and explicit security model. This seems
particularly relevant given the growth in support for downloading,
installing and running code from packages distributed by repositories
with no assessment or vetting of code. I find it quite inconsistent that
when I download and install a new theme, I have to explicitly mark it as
'safe', but I can download a package from melpa, elpa etc with no
additional checks or without having to agree to allow access to whatever
service or data it wants. 

I do wonder if it would be a good idea to try and document when org will
evaluate code in org files. This would include not just babel block
evaluation, but also elisp evaluation in table formulas, block header
arguments, file option arguments and possibly other subtle cases. This
may enable us to see if we have the granularity of controls correct or
identify inconsistencies and omissions. This information might then be
useful in defining a security model which could then identify what
controls are actually necessary and how to implement them to provide a
more straight-forward configuration for end users. It could also provide
valuable input into what additional tests may be necessary to ensure
things are working as expected. 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]