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 qDCrEn3UGmO3fAEAbAwnHQ (envelope-from ) for ; Fri, 09 Sep 2022 07:51:57 +0200 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 SEu+En3UGmNtYgEA9RJhRA (envelope-from ) for ; Fri, 09 Sep 2022 07:51:57 +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 A4B79FA7E for ; Fri, 9 Sep 2022 07:51:56 +0200 (CEST) Received: from localhost ([::1]:33822 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oWWvj-0004id-H6 for larch@yhetil.org; Fri, 09 Sep 2022 01:51:55 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42374) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oWWtd-0004hi-U1 for emacs-orgmode@gnu.org; Fri, 09 Sep 2022 01:49:45 -0400 Received: from mail-pl1-x62f.google.com ([2607:f8b0:4864:20::62f]:41493) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oWWtb-0007Mr-Ph for emacs-orgmode@gnu.org; Fri, 09 Sep 2022 01:49:45 -0400 Received: by mail-pl1-x62f.google.com with SMTP id p18so809564plr.8 for ; Thu, 08 Sep 2022 22:49:39 -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=9Vm+7ZODSUNFMTM4Qc0E6LJZhisacG4WPFVlrFq5EKU=; b=cp2uMEhGeQ5wtWRNKY1C6groch6gs19hH6GUI6JPXDrGj1PxepBrPFYfdvvhSLpq2P IF1CLK9pOO0jVjMWMRFZuONwa0+wL612XQsJuw5xACPy3Cpz3yNm+plZ64C3lXO+WukK Y/FQ0n/IOQCBc7TIoLE2ClAuaWVnI4Ilw0JlKhy+GqzrwKEvRrMFvPU01HwWWZCXSBYQ RQlFBoZ9tFRlW9/USHKBzc56cHil+QMfc3+iLWgLia+q0fI/T4lvwyb1SHPScZ5GcOn6 Ghc2Wt+apXa+4meJpYhTloOlKEut18us1QmJ48ZurpE941NoVk0/Wmqat2jjTA7Mfyv0 XWKg== 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=9Vm+7ZODSUNFMTM4Qc0E6LJZhisacG4WPFVlrFq5EKU=; b=NoGEsDKLh0GkxPcd658BzXpJJWzGKIRsdmoasS5jiPlUgHsP71v5QxYg4q3KKaQd6f NEhE/JA8tqkCihS3Fv0LtMeRi1fGg3xwLCXBRW6y6SHYstMGnJm6AtyoYxO4NgrOIjh+ e/e20m3NRBAYZ9LTG2VDbgLRXsLUJ+YSuXWkwQD5DwB6n3qZX7v+aGPV06DniS+AaN3R B6bCLF+Y+I3LhMWBcVJMt5vvgJ6NMrLock1XLaDIibIyDC6wcJw5Ab7jCJ1oV99eg7HP FzmXmXvGYdGDfCYutamfFZ5KUl5kHkmm/XutQEePd4lJ5NgUrKTXBW5cw5lQZhlHqfPl 0VMQ== X-Gm-Message-State: ACgBeo32onvVkeHaTOhj1+938hFwbBSQ2RMVs2Z71dZyI5yZXHquM1tw vpdf5Wf3UuOs8TJvqXuxyt0= X-Google-Smtp-Source: AA6agR7WnsbvF4yEX+jxbbjlzxnBwYN8vAyAWiWK0UJ/YRBOc0VkljFHp7OqimIUl1tPi1TTXlSSvA== X-Received: by 2002:a17:90a:bf13:b0:202:78ee:addf with SMTP id c19-20020a17090abf1300b0020278eeaddfmr4117722pjs.22.1662702579019; Thu, 08 Sep 2022 22:49:39 -0700 (PDT) Received: from localhost ([2409:8a70:2b2:5800:8ec6:81ff:fe70:339d]) by smtp.gmail.com with ESMTPSA id n62-20020a622741000000b00540a3252191sm677787pfn.28.2022.09.08.22.49.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Sep 2022 22:49:38 -0700 (PDT) From: Ihor Radchenko To: Fedja Beader Cc: "minshall@umich.edu" , "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> Date: Fri, 09 Sep 2022 13:50:32 +0800 Message-ID: <877d2ddrkn.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::62f; envelope-from=yantar92@gmail.com; helo=mail-pl1-x62f.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=1662702717; 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=9Vm+7ZODSUNFMTM4Qc0E6LJZhisacG4WPFVlrFq5EKU=; b=uruxks79NQvhveCusYXFYUz5Fzw9juAKM4AzpTu9nUD/uXOXP0frAp2VblHFAbil7wO9i2 nyU1fAEmKNqU6jKtWkzAgn9rWVPXDIwCzFPR6tQJByfy+4T+ykhUfDBGXzQhtcBqu7y0vH 6ofBbxxcQygBZuO4uCZwt+XkDIt5ClUtXS13wtMGGv2vp4aDWqp/4McMiCp+tT9AVuurUA gYcEbNzWVelI4pMIGqmNZ+4ujjMDTtv4Xd2K5JN/V47UArze8/TxAJC1t9wOVtBYko1jzD qNbwBaXKdLuiqGEToRu1DznaerU6oLiAZrLUaVuuOSix4I2K4t4reQ8bK7/g7A== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1662702717; a=rsa-sha256; cv=none; b=ZWMSRyiKWjGr33bT9TbjOTazMZUyTu0h65N1Sj5WobKCsUQdiRsGgugHRzHJHHHhQn43cS S4VPVdwtwZYjNoJh1XNFZj3Eb932KODO68RJNp55ouyj9I7+rI1Oen6DwmAt2Dh+GiZA90 fUncZ0xcL6TIe/oFNCJ6+m3DEdETaF7Itx4bMQRYiU8eAlZZImdm4LvHd8jAl71Vx+IRlj JQotpjQrKl2KuhgVhzlqrwngG3QYm6dccaUA//qKB1LAr6QV/k+wzFpg0LGfY1Z0m/EnIf 1ssGLUQE15r/V1XuyL8RI2bhMIkplDfGJqaV0e3N6kTwRag++4RCuxvCiXQZag== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=cp2uMEhG; 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=cp2uMEhG; 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: A4B79FA7E X-Spam-Score: -3.30 X-Migadu-Scanner: scn1.migadu.com X-TUID: a1rBdz7U4wNG Fedja Beader writes: > I'm aware that file-local variables exist, but it seems that > all documentation for them put them *into the file*, which is not secure for files downloaded from the internet. What is to stop a malicious file from setting an "yes, execute me automatically" variable? 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. > Anyway, the point of my email was to suggest a change to org-mode such that it provides a pleasant out-of-the-box user experience for people like me. I want to use org-mode as a python/octave/R/whatever interactive notebook without having to spend several days learning elisp and the internal workings of Emacs. I have spent these days, days that could be better (sorry!) used working on actual projects of mine. But I spent this time and the time to articulate what I want and to write these emails in the hope that I will be the last person having to do so. I would also like to suggest org-mode to other people instead of Jupyter notebook without having to add "oh, btw, you might want to add these three pages of alien code to your init.el to make it usable". I am sorry if any of the answers to your suggestion sounded hostile. 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. The above does not mean that we reject your suggestion. Rather we try to weigh on the available options in Org and Emacs itself and then try to integrate the new feature into the existing concepts/functionalities. > To go a bit further off-thread, this change might seem unnecessary. However, the other changes I want is also auto-executing all modified code blocks on file save and/or when the cursor moves out of it, auto-executing dependent blocks when their dependency changes (e.g. blocks full of constants) or marking blocks as stale. But I will make suggestions to improve these things in later emails, once I know what I want. Feel free to do so. Suggestions are always welcome. > Hello Ihor, > >> Then, what about the following: >> 1. Set org-confirm-babel-evaluate globally to t >> 2. In the files you maintain, you can always put >> file-local/directory-local value of org-confirm-babel-evaluate to >> nil. >> 3. We can modify org-babel-confirm-evaluate _function_ to accept four >> possible answers: yes, no, yes for all in buffer, no for all in >> buffer. The extra 2 options will set buffer-local value of >> org-confirm-babel-evaluate in the current Emacs session > > Don't know about option (1), (2) seems insecure at first glance, for the reasons mentioned above. (3) sounds good (yes/no/always/never?) and what I want. (1) is what Org uses by default. I mentioned it just in case if you have org-confirm-babel-evaluate set to nil. (Many people do use this unsafe setting). (2) Is safe because file-local nil value of org-confirm-babel-evaluate will trigger Emacs to show you a warning, as I described earlier. (3) Let me elaborate a bit. Yes-for-all/No-for-all may be implemented in multiple ways: - During the current org-babel-execute-buffer call - From now until the buffer is closed - Forever for this file path - Forever for this file path until the file contents is changed - For some period of time Moreover, the above may apply for all the src blocks in buffer or just a particular src block. 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: yes/no (each src block) Yes/No (all src blocks in current org-babel-execute-buffer cal) * (until the buffer is closed) ! (until the buffer is closed and in the next 30 days, as long as the buffer contents is not changed) WDYT? -- 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