Ihor Radchenko <yanta...@posteo.net> writes:
> Tim Cross <theophil...@gmail.com> writes: > >> 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. > > 17.13 Code Evaluation and Security Issues That page is a good start. However, I think it highlights why not having a clear model limits the utility of the options being provided. Consider this scenario - I am a reasonably experienced Emacs user, but wouldn't describe myself as proficient with elisp. I can do some basic stuff and I have an init.el file which I basically understand, although there are some borrowed bits which to be honest, I don't fully understand. I use org mode a lot. I really like literate programming and find the whole babel stuff really cool. I also make extensive use of tables and the spreadsheet capability to track statistics on my projects and use gnuplot, ditta and plantuml to generate plot, diagrams etc from that data. Obviously, I trust all the code in these files as I wrote it! On occasion, I get org files from colleagues. While I do basically trust my colleagues, I don't want to just blindly allow execution of the code in these files. I would like to check what the code does before agreeing to allow it to run. On very rare occasions, I get an org file from an untrusted source. In this situation, I want iron clad assurances none of the code from this file is executed. 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. How does this fictitious user achieve this configuration? Is it a reasonable expectation that most users will be able to write the elisp necessary to achieve this model? 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. 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?)? 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.
