Max Nikulin <maniku...@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.
