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: Ihor Radchenko
Subject: Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable
Date: Sun, 18 Dec 2022 14:19:28 +0000

Tim Cross <theophilusx@gmail.com> writes:

> Based on the information in section 17.13, how do I configure my Emacs
> so that
>
> 1. All the code in the files I wrote just runs and doesn't bother me with
> annoying execute questions.
>
> 2. Code in files from colleagues is shown to me and I'm asked if it
> should be executed. Once I say yes, I don't want to be bothered about it
> again i.e. next time I open that file, I want org mode to know I trust
> it.
>
> 3. Absolutely no code in files which are not from the two preceding
> sources is to be executed unless I explicitly approve it. 

Not yet, but I hope that we can integrate the approach we use in
`org-safe-remote-resources' and `org--confirm-resource-safe'.

> It feels like what we currently have is a selection of disconnect knobs
> which the user can tweak, but with no over-arching mechanism to help
> manage these settings for various scenarios.

Agree. I hope that we can slowly work towards connecting these knobs.

> Finally, are we 100% certain that these different code evaluation
> circumstances are the only ones? Can we be certain there isn't areas
> where options or variables are set which couldn't be used to evaluate
> code (similar to be previously identified execution of code in block
> headers which occurred before the checks on code evaluation?)?  

No, we can't. But it is true for any software that allows third-party
code, not just for Org or even Emacs.

And we cannot use the more universal sandbox approach either. Not in
Emacs.

> It also feels like the approach we have taken here is almost a throwback
> to a past era where he had a lot more trust. What we seem to have is
> protection against accidental execution of code rather than protection
> against code with malicious intent which has been crafted to be
> difficult to spot and deliberately takes advantages of small 'holes' or
> over-sight in the controls supplied.

I do not think that we can do anything about crafted code in Emacs other
than displaying that code and letting the user decide.

And I haven't seen any better solution, except anti-virus scanners that
are constantly fighting new malicious code.

At least, we do show the code. It is already better than "yes/no"
dialogue you get when running random executable on Windows.

-- 
Ihor Radchenko // yantar92,
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 via email to

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