From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id WAF0Hnubm2POagAAbAwnHQ (envelope-from ) for ; Thu, 15 Dec 2022 23:11:07 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id QMpoHnubm2OCQQEAauVa8A (envelope-from ) for ; Thu, 15 Dec 2022 23:11:07 +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 B507472CE for ; Thu, 15 Dec 2022 23:11:06 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p5wQf-0003QN-Hd; Thu, 15 Dec 2022 17:10:15 -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 1p5wQc-0003Q9-S4 for emacs-orgmode@gnu.org; Thu, 15 Dec 2022 17:10:10 -0500 Received: from mail-pl1-x635.google.com ([2607:f8b0:4864:20::635]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p5wQZ-00064z-Kt for emacs-orgmode@gnu.org; Thu, 15 Dec 2022 17:10:10 -0500 Received: by mail-pl1-x635.google.com with SMTP id d15so432683pls.6 for ; Thu, 15 Dec 2022 14:10:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:message-id:in-reply-to:date:subject:to:from:user-agent :references:from:to:cc:subject:date:message-id:reply-to; bh=FMCWf0mtsSdBORXSuSnE6GZn08ktuSCepxQ8kxRR+Dg=; b=E4ynMlEQ/MMb3ELIQZ5EDOmBP7DshbXkClwkG1cweuoEStFIScbaNszTWrw2nWVSgf jpulLIe49SqEXyUq4d7s3mjb6+RUR4IZSdkdJ88VJriQOska2VEMbNzmPfZgmLHTvcwy ylzPRAL54WYFwfH0mz85plKdREw5baDm9A58GC0Td1Zrh0YY6IwawERpOSG0iiastucG C3lsNRrHE7BArepr2Y8bVpwqRulflBAitKywcDPl7z0y4vnDJEHJ2uLVJgrlbCdxQlNZ zT/5mZpfAowOLLAke/LHaMyqPRFrH7N6pPKerOevwMHOCrbvyIGWuEPqOgxUhvk7t6AV LOMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:in-reply-to:date:subject:to:from:user-agent :references:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FMCWf0mtsSdBORXSuSnE6GZn08ktuSCepxQ8kxRR+Dg=; b=UKpCe+b+tgYWsMWoErHVUBCRD1491IzQTGZfFiDGtG+50i2za8OZjZ/wrjFFx80FC9 7StYM3WYLTAzB3XXoLkGjhzK8c42Y3XJqz/6BGBu5eblqXD79ds7oxhk7dy+ObyCoPu0 w+tZM8x9H/ZmBL0avxNEgYJh7OMZMgkliAnukBjsh7uI54uk7pZI5imZvC9v8TkSkNJH nZULbMWi/ukiHgVNfsAmdYPVXUXk+aX6qIdeB5O+ewwZXCvo4huihmOB+H3DlA6SRl42 0atBu1q14jRx0N8i1hbc2CGXaJnV9JdMhpbFmG89hqotjTVQJdUMZ+VMqvgds3qLczwk Hedg== X-Gm-Message-State: ANoB5pmbpwgIMw+RKK9ye8YaXDpPyxsj5YAm0YAwlfNBdOtFq2YBLjaa x+qZFAwfAAFB8ewXma3pa3Ynv13ZNPY= X-Google-Smtp-Source: AA0mqf4HHiiC/93EJs40Oi4eoaE3xD1I5l4wdxtbUJ1LeLSZ1SXGm7awPaiu0AJr4Ro/XP2wQhnpWg== X-Received: by 2002:a05:6a20:841f:b0:a4:64c7:a7f1 with SMTP id c31-20020a056a20841f00b000a464c7a7f1mr50065699pzd.14.1671142205663; Thu, 15 Dec 2022 14:10:05 -0800 (PST) Received: from dingbat (203-173-24-107.dyn.iinet.net.au. [203.173.24.107]) by smtp.gmail.com with ESMTPSA id v17-20020a63d551000000b00477bdc1d5d5sm214241pgi.6.2022.12.15.14.10.04 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Dec 2022 14:10:05 -0800 (PST) References: <87359ld5ye.fsf@kyleam.com> <874ju0j538.fsf@localhost> <87len9uj5s.fsf@localhost> <87ilicua53.fsf@localhost> User-agent: mu4e 1.9.7; emacs 29.0.60 From: Tim Cross To: emacs-orgmode@gnu.org Subject: Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable Date: Fri, 16 Dec 2022 08:08:28 +1100 In-reply-to: Message-ID: <86len8uxmu.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::635; envelope-from=theophilusx@gmail.com; helo=mail-pl1-x635.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-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1671142267; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=FMCWf0mtsSdBORXSuSnE6GZn08ktuSCepxQ8kxRR+Dg=; b=VhQLx99Q/sgf2bRCB5LufKtpq4kk14iz4KGwFPCy0a5B0wfhiomAWXzCWQwSKPkIrPpHpn HlD4FeCmsYatMPo5gr7tINc2mLLhSYUjq9jDJXLcvoeV62/3GfH296jAhkk2YDAQ0CE1hV ftCSGd0BwN+dzmNOgZ2aXdnDduw9ZMJocYs929jXDXvb2ZeH+jwcFq+6rYQEr+e6kJbbV5 sATsv7OshqeGf8v90yyap93ye4y78hzWv72XknBIP7BibVsf6H+Y712LxGt1pX/cyjP6+D uac18UKVNxT1Fp7TgeCbe/f6OR9oGTyb77QLuuB7PI5skbIKw1+U0WEbNVlvwg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=E4ynMlEQ; 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" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1671142267; a=rsa-sha256; cv=none; b=Ju3H6HQ17YDpt5VKmNzeLu9yKPLH+XCd5S0cjylimKQqrN6mGJO5dIhrGuvOiEEVTwsa5j RurMW//1R881P+VrC8J0BjKhULqSxAtNzYH9ZrLkOfa8ge1BKH05MF6lR7ZpDIrAt+qWjE J/EAj+pNH4IQX2w6OTcnfGaNgjtnIMYqfATVqgY3NCQFcKUud2CKj5qLD7J556wQNYBxyH g3+jzFDn6quG9xRWYYNXlCxUsJB4f7lYeDU5MdjKB2immKxKvWEQRqmgW7X42SOhnB0deM pQT5N8g6xKzt8aiSCn5GQTtqwHWce0hftvvAZEFtjImBO3xe2E0KNtg1wWi2Iw== X-Spam-Score: -4.47 X-Migadu-Queue-Id: B507472CE X-Migadu-Scanner: scn1.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=E4ynMlEQ; 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: -4.47 X-TUID: 6od3PKaJfkSI Max Nikulin writes: > On 15/12/2022 19:25, Ihor Radchenko wrote: >> Max Nikulin writes: >> >>> I would consider reverting the commit causing user prompt for every >>> variable. >> 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. > > Perhaps advising `org-babel-execute-src-block' with `y-or-n-p' is a better treatment for > my paranoia. > >> 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. > >>> https://list.orgmode.org/Y1uFDWOjZb85lk+3@protected.localdomain >>> Re: [BUG][Security] begin_src :var evaluated before the prompt to >>> confirm execution >> How is it related to the current discussion? >> The purpose of the security feature discussed here is not for web >> browsers or anything like that. > > I am not going to add malicious source blocks to my private org files. For some code it is > better to have a prompt, but generally the issue is not excessively important. I tend to > inspect org files fetched from net in some other application at first (browser, less, or > vim). > While I would argue that is a good practice, it isn't always practicable for all users. For example, Emacs together with Emacspeak is my primary accessible interface. While I could use a browser, it would be severely inconvenient and frustrating. I have to admit I also have some concerns here. These may or may not be well founded. My biggest concern is that we don't seem to have a clear security model. It feels like we are responding to security threats in a piecemeal and reactive manner and without any clear model. As a result, there is a risk we will end up with a complex solution where we don't fully understand how all the separate pieces interact. This could result in a complex configuration with a low level of confidence, two of the worst attributes to have when it comes to security. > Accidental evaluation of code is a real danger for those who insist on opening links to > org file directly in emacs or even propose to use org as a kind of browser. I raised the > security issue in response to passionate messages demanding direct ways to work with org > files from the web. I decided to remind the context with hope that it would help to > reevaluate severity of the issue. > My concern here is that given the power of link configuration, source blocks, local variables, .dir-local, evaluated block header code etc, it is extremely difficult to actually know when code will be executed. One thing I do feel is a risk is that if we don't get the right balance, the questions about code evaluation may fall to the level of annoying noise which people get rid of by simply enabling all code evaluation without question. Obviously, this would be a very bad security decision, but as we know from years of experience, users will frequently prioritise convenience over security. If they are unnecessarily 'nagged' regarding code evaluation, I suspect this is what will happen (noting that unnecessary is very subjective). > I do not have a better proposal, but I think I see movement in a wrong direction. I'm not sure if I have a better proposal either. I'm not even sure if this is solely an org issue. It could be that Emacs itself needs a clearer or better understood and explicit security model. This seems particularly relevant given the growth in support for downloading, installing and running code from packages distributed by repositories with no assessment or vetting of code. I find it quite inconsistent that when I download and install a new theme, I have to explicitly mark it as 'safe', but I can download a package from melpa, elpa etc with no additional checks or without having to agree to allow access to whatever service or data it wants. 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.