From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.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 MHnPDk6mHWPjLQAAbAwnHQ (envelope-from ) for ; Sun, 11 Sep 2022 11:11:42 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id KGyFDk6mHWOlXwAAauVa8A (envelope-from ) for ; Sun, 11 Sep 2022 11:11:42 +0200 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 079B0B313 for ; Sun, 11 Sep 2022 11:11:40 +0200 (CEST) Received: from localhost ([::1]:36684 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oXJ06-00012A-VZ for larch@yhetil.org; Sun, 11 Sep 2022 05:11:39 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35972) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oXIxu-00011u-Uy for emacs-orgmode@gnu.org; Sun, 11 Sep 2022 05:09:24 -0400 Received: from mail-pl1-x62b.google.com ([2607:f8b0:4864:20::62b]:36595) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oXIxs-0007sL-IX for emacs-orgmode@gnu.org; Sun, 11 Sep 2022 05:09:22 -0400 Received: by mail-pl1-x62b.google.com with SMTP id c2so5830828plo.3 for ; Sun, 11 Sep 2022 02:09:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc:subject:date; bh=spo/rWd9QW9x8lXK7mWlF0hv0jwpwhBh8ImZawOohFA=; b=NRuEJBwGBVry5PipDGJ6jLqthvO7s7OgNC9G+KVGcVpR4wNcRDShdD1d/+K9PZdx3m g13L/2+/S4Ot/b9hVVMZtTILrvsrfGCQfYU5Ouq31HDz36F+9bikzcY0qClUsiXkVxgW i2eAPjVJB0PYyDLVuC13Vvt679SxJa9pSsI4WYagEdq6oHTTR/TE9E9ZHyFi8IT0kpOM JbOADewt7mvtF4yWvHzBaeIunKpuHvECAEdk1oT+3xjyk6mE0IxNOd7MZqgv798Q7vE/ /bWd+AWYkrhJM0FgyWbVWJnoR6UR+xAgs2FoZMEozRsvJ/iLUssbopc9nCEHmNeyhiVn kvVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date; bh=spo/rWd9QW9x8lXK7mWlF0hv0jwpwhBh8ImZawOohFA=; b=UdTVu85UKqF7lW1OBFexih8Z09kGND/s4MYf1/3iF4NHQmFNDWvIhkhofNPnGUruqc N/tp3jvQ5r13+Er7g8pSJKFInAtNlaMzIvw37u5PTQohsJUsB7931RvyuPR5KO1y0KF3 4E5ZetuCiI8umMMD5WUm8+MgTqAQipWVL0Dir0cQBuDma8zthtSwhNRr9tbT20btJBIy ILBg4CAEM/Q40fI1ExljBu4L4VIjUF838+mmEr1wv0tYCSop/WE0r+tSgUb5W+eLsaBW y7hXJ+/8CSwTmoJu1myxKgiZ6CrgaPuK+mdV14+uelw3HsQO19uverZEqNGlKhYFIOUd GyPA== X-Gm-Message-State: ACgBeo0GhvGTpvcBi0yB6k2xUJ5s7r0DV1IYRVBdy1UuwKYYg1+xmmSZ kbaLWTj+y5o33sBywD4sEACOabq4jZM= X-Google-Smtp-Source: AA6agR66SL5PwfFdocnhcPe6KIjHd5fNXSp/LxwEG28/amfhKrW0/yU4dFJ1tIn05HR12eSizU14Cg== X-Received: by 2002:a17:90b:3809:b0:202:b482:b7d6 with SMTP id mq9-20020a17090b380900b00202b482b7d6mr4959184pjb.209.1662887358278; Sun, 11 Sep 2022 02:09:18 -0700 (PDT) Received: from localhost ([2409:8a70:2bc:c850:8ec6:81ff:fe70:339d]) by smtp.gmail.com with ESMTPSA id w14-20020aa7954e000000b00535e950aa28sm2941599pfq.131.2022.09.11.02.09.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 11 Sep 2022 02:09:17 -0700 (PDT) From: Ihor Radchenko To: Fedja Beader Cc: "emacs-orgmode@gnu.org" Subject: Re: per-file (or, really, per buffer) allowing/disallowing code block execution In-Reply-To: References: <595135.1662491125@archlinux> <87zgfao1hu.fsf@localhost> <877d2ddrkn.fsf@localhost> Date: Sun, 11 Sep 2022 17:10:06 +0800 Message-ID: <8735cyxonl.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::62b; envelope-from=yantar92@gmail.com; helo=mail-pl1-x62b.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1662887501; 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=spo/rWd9QW9x8lXK7mWlF0hv0jwpwhBh8ImZawOohFA=; b=PEwK1cg1uV5SocauGW5WFkT+WvToAjYP+EmrJDUAaBQkS1W1eJ6yBOH5Pqg7LnhRjPtX90 Q1busCJVEa+py6T/8YUlWGfsC17eX6DuUV22iKHCuBo3Ywmjyrw3sBiM/32hwhDnf56GfR 26J4X9Fk4kpBXn8pY3OVfMh1WjkV72jb/GDi2imK8oaKOz836Jbo1xO7zUe1fFr/xrQdzy DY4cm9Kja6UDW3T3gBosSB14rJJeJywdHGWB6Hk76wrmk/8iLhANHXrYS4GlOyIovc2tin ILES6kmrvdPnd2eClPYrl4c5IEziMX7PdAXX38KFvbFVFhivx5Pww7vB4dvdQg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1662887501; a=rsa-sha256; cv=none; b=RuCihUlXaMsHYYVlUfSH2hCqoHaPU82zJsfzHOigx6AKXdj9+yx4IJWhxwehxZm/AinyzR JCg+yhmv9j4p/d9XwTxvjCTk1gvuLX1liWpdd2rqSS56TKXrjoh1BUJiTA3iL8cVkzM0Hx WjBZxTOROU/NV7pAAweNC6e6FzIhMcT51jZjrSpws9vYhWdDWHqTeC56CEIdzTII9bTUar Vnjao6BepQXgHTBzeOFETCJHRCRmgspJPIRaKlT8Wxm2reKf/FyQLW0Li/MwH7IBkufxIf ElZ97tbSRi1D1fOO3epxhu7QRHwzfwb+QXwWVWwwz1YgHDuWgbbb2IjZt0Kc4w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=NRuEJBwG; dmarc=pass (policy=none) header.from=gmail.com; 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" X-Migadu-Spam-Score: -3.30 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=NRuEJBwG; dmarc=pass (policy=none) header.from=gmail.com; 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" X-Migadu-Queue-Id: 079B0B313 X-Spam-Score: -3.30 X-Migadu-Scanner: scn1.migadu.com X-TUID: royz5TJ9PSns Fedja Beader writes: >> As Tomas pointed out, Emacs has a concept of safe and non-safe >> file-local variables. org-confirm-babel-evaluate in particular is only >> safe when it is set to t (query execution). If your downloaded file >> attempts to set org-confirm-babel-evaluate to nil, Emacs will show a >> warning and ask you whether you want to use this unsafe nil value. > > Can this mechanism be relied upon? I see in > https://www.gnu.org/software/emacs/manual/html_node/emacs/Safe-File-Variables.html > that user may press ! to mark everything safe. This is less effort than > the explicit "yes" required for executing a block on C-c C-c. While I agree with you, most people appear to prefer a single char. In fact, it is very popular to replace _all_ the yes/no prompts in Emacs with y/n prompts. If you have an interest to change single-char prompt for buffer-local variables, feel free to file a bug report to Emacs. AFAIK, there is currently no way to customize this prompt. >> Note that Org mode already has a large number of customizations, which >> is why we are trying to not introduce unnecessary customizations. Too >> many options is not always a good thing. > > This makes me wonder how many of us have a custom init.el for > the purpose discussed here. Surely I am not alone, and surely > having such customisation maintained in org-mode itself would > be better. I personally rarely use org-babel-execute-buffer and thus changed org-confirm-babel-evaluate to nil + added default export :eval no-export header arg. Since I run src blocks using C-c C-c, I always see what I am about to execute. >> Yes-for-all/No-for-all may be implemented in multiple ways: >> - During the current org-babel-execute-buffer call > > If the user determined that it is safe to execute all blocks > once, then why would it not be safe to execute them again? Consider a code in Org file that makes dangerous things. It may be useful to keep a query about execution just to stop and think for a moment if you really want to do it. Not for every block in buffer, but once. >> - From now until the buffer is closed > > This option is probably closest to what I want. > >> - Forever for this file path > > Also fine. But > 1) then this would have to be stored somewhere outside > of the file, else the user would still be asked if they > want to load that unsafe local variable. Meaning that in > that case babel could just ask the user directly. > 2) As I learn to use Emacs, the number of restarts > decreases, meaning that the session just lives forever. > In that case the once per open nagging of babel > is acceptable. The second option is a bit more consistent with file-local variable handling and, more importantly, with `org--confirm-resource-safe' - the approach we use to download remote #+SETUPFILE. >> - Forever for this file path until the file contents is changed > > What would change the file if not the user, and if the user > already approved the existing code, why would the user > not approve their own additions to it? > >> - For some period of time > > Same response as above. I was mostly thinking about a file being replaced by a new downloaded version. This is probably an overkill though. >> Moreover, the above may apply for all the src blocks in buffer or just a > particular src block. > > Going through blocks one by one and whitelisting, then executing them > seems like a reasonable course of action, so why not. > However, it might be a bit difficult to implement? > How would babel determine that a block is the same > one, even if it changes? Position in file? We can use the same approach with :cache header argument. However, I feel that it is also an overkill and will rarely be needed. >> I doubt that all the options should be implemented in practice. We may >> probably just allow yes-for-all when running org-babel-execute-buffer >> but not individual C-c C-c on src blocks. I can see valid reasons to >> allow (1) in current org-babel-execute-buffer-call; (2) until the buffer >> is closed; (3) until the file contents is changed + limited by time. >> However, 3 possible options in the dialogue may be disorienting: > > I would like the option to mark whole file as > trusted without having to execute all blocks in it. If we use the approach similar to `org--confirm-resource-safe' and `org-safe-remote-resources', the safe files will be accumulated into a custom variable. That custom variable can be modified by user just as any other custom variable. >> yes/no (each src block) >> Yes/No (all src blocks in current org-babel-execute-buffer cal) > > all/none? always/never? > >> * (until the buffer is closed) > > allfornow? alluntilclose? > >> ! (until the buffer is closed and in the next 30 days, as long as the >> buffer contents is not changed) > > I'd prefer having to type full words, > so that it is obvious what the user meant. I also prefer full words, though it will be slightly inconsistent with file-local variables and remote resource query in Org. Summary: 1. We can modify `org-babel-confirm-evaluate' to allow 3 extra answers: - All (or maybe Yes, consistent with common bash script query) - None (or maybe No, consistent with common bash script query) - Always The new version can be modelled after `org--confirm-resource-safe'. Never is futile because user executing org-babel-execute-buffer will not expect the command to be ignored. Always will not be shown if `org-confirm-babel-evaluate' is not set to 'prompt or 'safe. 2. We can add C-h help buffer detailing what the answers to (similar to query-replace prompt) 3. We add a new custom variable org-confirm-babel-evaluate-safe-paths that will hold files marked safe. 4. We add two allowed values to `org-confirm-babel-evaluate': 'prompt and 'safe, just like in `org-resource-download-policy'. The default will be changed to 'prompt 5. We document changes in the manual and in the NEWS. Patches are welcome! -- Ihor Radchenko, 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