From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id WO7NE3cjr2O6OwEAbAwnHQ (envelope-from ) for ; Fri, 30 Dec 2022 18:44:23 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id uDzoE3cjr2NapAAA9RJhRA (envelope-from ) for ; Fri, 30 Dec 2022 18:44:23 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id D8A3BE1B1 for ; Fri, 30 Dec 2022 18:44:22 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pBJQL-0001iH-0i; Fri, 30 Dec 2022 12:44:05 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pBJQH-0001h3-Ij for emacs-orgmode@gnu.org; Fri, 30 Dec 2022 12:44:01 -0500 Received: from mail-yw1-x112b.google.com ([2607:f8b0:4864:20::112b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pBJQF-0004W0-Qa; Fri, 30 Dec 2022 12:44:01 -0500 Received: by mail-yw1-x112b.google.com with SMTP id 00721157ae682-417b63464c6so305463307b3.8; Fri, 30 Dec 2022 09:43:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=rPZumoaOe2K+sWTlNYS7gAaV7W9dRxxn/9SrOpv6rx4=; b=ddI0SIFsLiqoi25wXtW47EONcDh+KOhDyr+tfi4uzdPXs5fxoTHDkdIb63/2htjxUr vkglQGd9G9VYu4KnJCVPXVNWrnpI+HwyphNQQxAQ5RDz7ZiDuw2JQVRcYH33JuFT0qYt kbetMynhWu0vjRQzrlpOvuXqWY5F+pv774eNfXx6RrPt0b/PIdMN/FTLKBLwa2RgYdeN MzDJ87fhgPPwllRw/W6ZKU6c0IGi/itRk9xKvp3kXvG7055QI0U1tMdjcrJS/WWo/lCS FEuFvDHEHDc5q2x1LlIJKGTFd0MD2sMtTcIGBp78gWW0pE5fxSM9Uku8DTZQbhoTfUcl 0I7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rPZumoaOe2K+sWTlNYS7gAaV7W9dRxxn/9SrOpv6rx4=; b=fW+J78nO8vrOKyAsrpdZmUKF5+tpKevOMpa8qWOzVtwKCUPckf2XlBnDZeRhOvjB9O NGD9GYTbQv4dGXQAnUFuNWQ/sKjLRF4PFycE0lcAw+Dw2cq2qy4xZG1BgVbyfuG2z+2d jZsyfudaD8A3wpJj+EN3lg44VYL+r++laoe3tJznxKAYkOFetxRFwdOX5NOpxwfQvwPs xlObuIvvvCZ8Napo6ZK6Cr44PhzzfNlLZOKJuKFgazRNoze4LgPjIX4gKkm70rUbMRps 9508waECHUU/B4NVr5w9MQ33SJjYVJKIklANPGFNI5hCWhGFeioU+g2iKR3F51k6waIa ph5A== X-Gm-Message-State: AFqh2kqQ4Pnl4jaGlErKXVwvpn2TZxLSbP3eXOQGQ6gq4r6k2rMnMtYf YlW6S35mhbuIkxr+NUCCMNmeA2wyCzWm0dButM6toj0Wlok= X-Google-Smtp-Source: AMrXdXsiMIhDvsIjGgQHk2wPHij4vORsCdMwSlLzSvKTwlnbPLw7xo5KwDSUMUWbedeWL5Unbq0fR2wiRe83taUMP3A= X-Received: by 2002:a81:54:0:b0:357:858c:e015 with SMTP id 81-20020a810054000000b00357858ce015mr3835173ywa.71.1672422237064; Fri, 30 Dec 2022 09:43:57 -0800 (PST) MIME-Version: 1.0 References: <87359ld5ye.fsf@kyleam.com> <874ju0j538.fsf@localhost> <87k02fspxa.fsf@localhost> <87edsii4mo.fsf@gnu.org> <87h6xetbfn.fsf@localhost> <878rips273.fsf@bzg.fr> In-Reply-To: <878rips273.fsf@bzg.fr> From: Tom Gillespie Date: Fri, 30 Dec 2022 12:43:45 -0500 Message-ID: Subject: Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable To: Bastien Cc: Ihor Radchenko , Kyle Meyer , emacs-orgmode@gnu.org Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2607:f8b0:4864:20::112b; envelope-from=tgbugs@gmail.com; helo=mail-yw1-x112b.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN ARC-Seal: i=1; s=key1; d=yhetil.org; t=1672422263; a=rsa-sha256; cv=none; b=DHDDcQ/no8xL034KaESR0FfoN5ddmQ6pcHl0PWuAij7vvAgyR2I0gcV21MALuknEWSl1Jq 6N+gZNs4FmOE5TzCsIdHWWPNfV0sNugDegx2QJt8p238GhT9fCRKIS5hQNcwb8yKUtgBIG xehK9gAruY8lUZD1FkfQVQ5paMMUl2xEoQYeRBX5TLjPS8anb//71VdMDfqiUxZ3yKs1zW JA6lHoKi69zisuGxtNsVelgfJFEkR+RnDyJii0Q3ePykj73l7srl8mBHtYKw97cco/D7Zb XCnMwaiYCvtBSwjXQz9c5c5apTM/A12kEYmTtjMMtpxZ67q1yksU8N/Q/2079w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=ddI0SIFs; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1672422263; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=rPZumoaOe2K+sWTlNYS7gAaV7W9dRxxn/9SrOpv6rx4=; b=iggNNTZB0iwFo4HmYxOapYlBbpMXkq/BXkIAB5B25QjusD2z/A+0DpGn+UC29j2b03d84H 8Q/knZwoOs43jLudm1so167WHNPFyo4G4c1YPfT/gWfDz/RnzuTscvM31Nss2dKDzGmCoU zyJY7PDScan4VGxY11GlH8NsQSP9lZxExhxPX0BXNdfYnFaWuuBbg9AlBxo4vOmsTwisql 926gyfjka6DVGit62SjRF7/QHf+lZSriypuSwO5EyjMlnP01zKyWhTSTB04FqI4o5yTjZX ZtfglyzYf2l1YBdFohQVMluFTIm5rvijpsjcmz/aU7kddDQzEnPYkgnEwmnw+A== X-Spam-Score: -5.92 X-Migadu-Queue-Id: D8A3BE1B1 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=ddI0SIFs; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com X-Migadu-Scanner: scn0.migadu.com X-Migadu-Spam-Score: -5.92 X-TUID: J0uGNKfrpa6R Hi Bastien, In short, we need two variables due to the case where a user wants to set nil for all vars and a function for code. More replies in line. Best! Tom > I see nothing in etc/ORG-NEWS that describes this change: am I missing > something? Looks like any mention of the change is missing to me as well. > >> Whether it changed or not, what is the problem in 9.6? > > > > The problem is that Org now displays more queries. > > > >> How does the patch solves this problem? > > > > It allows disabling these new queries about lisp evaluation outside > > code blocks without disabling code block eval confirmation completely. > Is there a real use-case for this? Yes. To give one example. I have many files that need to run hundreds of cells at tangling/export time. I have reviewed all the code in the cells and know patterns that are safe and wont' burn me. I do not want to allow execution of code blocks blindly during tangling and confirm eval is a secondary line of defense against running those blocks during export. I want to allow the cells to run uninhibited as they did before this change, so that I don't have to fight with org during the tangling process. As it is right now the change has completely broken various CI pipelines for me, and if these changes do not get in to emacs 29 in time I will be unable to use emacs 29 for CI until they are in the base image without having to resort to insane hacks and massive additional configuration changes to work around the issues discussed in the loading multiple org versions thread. > It looks like the patch fixes the "too many queries" problem by > providing a setup that is similar to what was the previous default > (i.e. only asking about code block evaluation when > org-confirm-babel-evaluate-cell is set to nil.) This interpretation is not quite right. org-confirm-babel-evaluate-cell has no interaction with evaluating code blocks, only with evaluating cells. When org-confirm-babel-evaluate-cell is nil or evaluates to nil then the org-babel-confirm-evaluate code runs on a fake block that is created out of the cell. (This is where there is still a bug that I mentioned up thread.) > But are we sure that users need to confirm header args evaluation > separately from code blocks evaluation? I am sure that in my workflow I want them split, especially for global nil/t behavior. I need to think a bit more about your suggestion to add more values to org-confirm-babel-evaluate to see whether it might work and what the relative complexity would be. It seems to me that duplicating the variable is certainly easier to maintain, if not to explain to those who do not use babel regularly. I would be interested to hear from other babel users their thoughts on the design, because it seems obvious to me, but again I wrote the code so am the last person whose view on the clarity of the should be considered. It seems that it was not clear to Max initially. > IOW I have difficulties understanding when these would be relevant: > (setq org-confirm-babel-evaluate-cell nil) Anywhere that a parenthesized elisp expression occurs that is not in #+begin_src block. > (setq org-confirm-babel-evaluate t) Only inside #+begin_src blocks. > I think that's the best route: providing, optionnally, more, while not > annoying users who don't want more. I think this is probably the right default as well. > > Yes. Ideally, we need to improve the code evaluation query. It should > > allow confirming evaluation in bulk and add some code blocks/files to > > whitelist. Similar to `org--confirm-resource-safe'. > > I see, indeed. Improving general code auditing prior to evaluation of blocks would be greatly appreciated. The fighting between the minibuffer and the primary buffer for priority and the fact that you often cannot see that code that will be run is a significant issue. However, this is orthogonal to the issue at hand. > > A concern have been expressed that more queries may annoy users and > > drive them towards setting `org-confirm-babel-evaluate' to nil globally. > > Upon doing this, the future more flexible security queries may be not > > used by such users. > > The future more flexible security queries will be made visibile enough > so that users currently setting `org-confirm-babel-evaluate' to nil > will *want* to have a look at it. Yep. We need to get the fundamentals in place to enable those workflows. I'm too paranoid to simply set that variable to nil, even when I'm only running code that I wrote, but I suppose that is not the case for everyone. > I find "cell" confusing here (as Max said earlier in the thread). It > either refers to a table cell or, in Elisp jargon, a "cons cell" (or a > "function cell"). I also dislike the name cell, but i'm not sure what to call it instead. I mentioned "parenthized elisp expression" above, since strictly speaking they aren't closures, they are any valid elisp sexpression. In the context of org-outside-emacs I imagine a day when those top level expressions might also be written in some other language and there would be some way to indicate at a file or section level or perhaps even single block expression level what language a given cell should be interpreted as. In the context of naming this means that "parentized expression" might not be general enough. Maybe embedded-code or embedded-expression? org-confirm-babel-evaluate-embedded-expressions? > What about modifying `org-confirm-babel-evaluate' to allow these values: > > - t : confirm header vars *and* code blocks > - 'code : confirm code blocks > - 'vars : confirm vars > - nil : don't confirm > > and set the default value to 'code, while allowing concerned users to > set it to `t' -- until we have a better system for evaluation query. > > WDYT? In short this is not a viable solution because there is no way to compose nil for embedded expressions with a function for blocks. We really do not want to change the function signature for the function to also have to accept whether it is a block or an embedded expression. That will break code for everyone. The solution I have proposed keeps blocks and embedded expressions orthogonal precisely to avoid these kinds of major disruptions. Better for users to be confused about how to use a variable but be able to learn about it or ask about it than for all users of a feature to have to suffer major breakages to their existing workflows and have to rewrite existing code to work around something that supposedly increased security. Having two separate variables is the only way to retain backward compatibility and give granular control over evaluation of code blocks and embedded expressions.