Max Nikulin <maniku...@gmail.com> writes: >> 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.
To clarify, I do not consider this patch to be the end state of security handling. I do plan to extend the code evaluation query in a way that it can be used to allow "All" in current command call, session, + mark files as safe, similar to `org--confirm-resource-safe'. Just not yet in this release. So, I don't think that the code is going to be dead. The new variable is also in line with the existing `org-link-elisp-confirm-function', `org-link-shell-confirm-function', and `org-confirm-babel-evaluate'. > Perhaps advising `org-babel-execute-src-block' with `y-or-n-p' is a > better treatment for my paranoia. Emm. No? The main issue with `y-or-n-p' is that it treats <SPC> as "yes". I have pressed <SPC> painstakingly in prompts too many times to consider y-or-n-p safe. >> 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. No, not really. From skimming through grep buffer, most of the calls are not inhibiting `eval'. -- 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>
