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 QFzmE6aMn2PjBwEAbAwnHQ (envelope-from ) for ; Sun, 18 Dec 2022 22:56:54 +0100 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 QLbXE6aMn2O3hQEAauVa8A (envelope-from ) for ; Sun, 18 Dec 2022 22:56:54 +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 B819F2644F for ; Sun, 18 Dec 2022 22:56:53 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p71db-0008Ee-A4; Sun, 18 Dec 2022 16:56:03 -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 1p71dZ-0008Dx-9f for emacs-orgmode@gnu.org; Sun, 18 Dec 2022 16:56:01 -0500 Received: from mail-pj1-x102c.google.com ([2607:f8b0:4864:20::102c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p71dX-0001If-I4 for emacs-orgmode@gnu.org; Sun, 18 Dec 2022 16:56:01 -0500 Received: by mail-pj1-x102c.google.com with SMTP id t11-20020a17090a024b00b0021932afece4so11161913pje.5 for ; Sun, 18 Dec 2022 13:55:59 -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:cc:to:from :user-agent:references:from:to:cc:subject:date:message-id:reply-to; bh=KHnOIAMAaA9RiyoHudygTeDB4oPtvUDeiR61rx5Mq78=; b=K3fOydpIhbtcuB2tYIOFa08qszRHW+icPGQ5PkCEj2QNnnT8jYjg24WDRNJEQzvKZI +DbJMiieORKG9BCxI1hJ4FlYNzdpju3Ke7ovCBqsmm3+Nqp3GIhFYDpWRqH0odfiCJfR GUJGx3KzMNFclR1OJtdsf1zLAXAtR+P+QmxdLDl+z/JtgbtJHGaUeBRSZeCaYopw0Cme M9aTYPs8xAQjDAQwSOXO7x6vmMkg9+oAV6vMk4BcwmDz01HZTyXCI3IN13yJ7FwFt1hB G7jawFuWef39sT8BuBAv6I3VmhTyaCj/NKegDCfU1m1LxVBOG2SYguf8tqmOMBoXQVui 9DPQ== 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:cc:to:from :user-agent:references:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=KHnOIAMAaA9RiyoHudygTeDB4oPtvUDeiR61rx5Mq78=; b=0eRRaXCbqjPagZv3eJWVHetpOQdWltzPxx0wEgqbNQjMD8EJogm9waWL5DjPoSs6Ww V1aXOe/AmPk5rqjTEYCLP9TzsLBVIaoL9tVUZI/UupCWRnAkHpU96xnNU8WJlM00yZd3 bnIjT507oPpZKEhINk3GgvWVoJHg7sdFP5Jlj3swqMQw7ka5UKo5x9k6w2Jep4MdofIv l+CH53CDeULtndhbq81x1a8LtJUO/JF5VKckjVaYANYwAiD+umoas+3Xb0mvFrk+oMBv RiCaBxlHhNl+1rcMIkOEFvwEKksB8UsPrB2BtvxFh+dMHjvCEcPORXEVx6HlrwpN6mDz uJrA== X-Gm-Message-State: ANoB5pmoPLUAIGCPq6hS4239I5E5t0X0SxUghPtyWXSh3Dwv1IdYNELS V+9oFvKtnrH7+22gtN4XcAYZGGMUNnI= X-Google-Smtp-Source: AA0mqf5Lj7OU1t5htLgO1GiDT5iVxH9kECZzJ4wqQyACNeGoK1P42uG0bTh3n3Kd9+bDI7vViSkKcQ== X-Received: by 2002:a17:902:ccc8:b0:188:640f:f41e with SMTP id z8-20020a170902ccc800b00188640ff41emr48564522ple.4.1671400557718; Sun, 18 Dec 2022 13:55:57 -0800 (PST) Received: from dingbat (203-173-24-107.dyn.iinet.net.au. [203.173.24.107]) by smtp.gmail.com with ESMTPSA id o4-20020a170902d4c400b00187022627d7sm5560182plg.36.2022.12.18.13.55.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 18 Dec 2022 13:55:57 -0800 (PST) References: <87359ld5ye.fsf@kyleam.com> <874ju0j538.fsf@localhost> <87len9uj5s.fsf@localhost> <87ilicua53.fsf@localhost> <86len8uxmu.fsf@gmail.com> <87o7s3swyt.fsf@localhost> <86h6xvvl30.fsf@gmail.com> <87k02o6bgv.fsf@localhost> User-agent: mu4e 1.9.7; emacs 29.0.60 From: Tim Cross To: Ihor Radchenko Cc: emacs-orgmode@gnu.org Subject: Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable Date: Mon, 19 Dec 2022 08:37:08 +1100 In-reply-to: <87k02o6bgv.fsf@localhost> Message-ID: <86tu1sidg6.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::102c; envelope-from=theophilusx@gmail.com; helo=mail-pj1-x102c.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-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=K3fOydpI; 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=1671400614; a=rsa-sha256; cv=none; b=uB9lRPstA9chmos9NCWdQjNr8UEqvl5X+0IawrTwRutAsefwg2WjqSE3s/OUbBW3MZhkfZ Ylq+vchCTb899HrhET7s3vIOZNk9n0SrKa9jto6dYLVd0Jx+VqkCEP2iBHAYjsAxV5L4PD sPazHJYcpyh7tCJPvd7/1wRZCqU3Ebl/hoCdD6Oetpg8kdfT7yBceM7nBaF9lcbdkMzYGT jmDBYRBLovv0x8N6zvtRrNc1BAy9qpS13qmxyBDiQAz6U/EThJEE7Z2eeDuZh9Ny7PtQDl 15X4RKCOsY7dVa+SqSUtlrrX+dBp5lLMnSCtlTRG914L76BhuStTGm5PzjbvSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1671400614; 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=KHnOIAMAaA9RiyoHudygTeDB4oPtvUDeiR61rx5Mq78=; b=C3WpwktdoWTDn0Rsd/CO4aZfRx0MNW+9RL9GCaARsDgJW2vklr0t8ByKcVVZDaVqKcKYSi lpGBnt14Pk+0i29VZXTu2u1KQwbOHH1L3Vb0cleGJ91FJjahJRlYiF/4hFr1UGh0MVuAcx AH2iWVlujA5/5FpZToYHeDsgkrTMK3XQLPPsz4I37RT39ubg32Aat7W3gHqhBemf0ssM/5 i90575n/2YWRySrV50eyJgfxdoa62eX69CGqO2C+bp8eV/wkau9u1ovvySCGCCrE1JtGtL nykns7hElgk5Qy1wAOphQGI1BTWI9cj0srbcZc+OMH6FInWFXjetl++QjZd+yA== Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=K3fOydpI; 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-Scanner: scn1.migadu.com X-Migadu-Spam-Score: -5.99 X-Spam-Score: -5.99 X-Migadu-Queue-Id: B819F2644F X-TUID: ILeO/mysdWX6 Ihor Radchenko writes: > Tim Cross writes: > >> Based on the information in section 17.13, how do I configure my Emacs >> so that >> >> 1. All the code in the files I wrote just runs and doesn't bother me with >> annoying execute questions. >> >> 2. Code in files from colleagues is shown to me and I'm asked if it >> should be executed. Once I say yes, I don't want to be bothered about it >> again i.e. next time I open that file, I want org mode to know I trust >> it. >> >> 3. Absolutely no code in files which are not from the two preceding >> sources is to be executed unless I explicitly approve it. > > Not yet, but I hope that we can integrate the approach we use in > `org-safe-remote-resources' and `org--confirm-resource-safe'. > >> It feels like what we currently have is a selection of disconnect knobs >> which the user can tweak, but with no over-arching mechanism to help >> manage these settings for various scenarios. > > Agree. I hope that we can slowly work towards connecting these knobs. > >> Finally, are we 100% certain that these different code evaluation >> circumstances are the only ones? Can we be certain there isn't areas >> where options or variables are set which couldn't be used to evaluate >> code (similar to be previously identified execution of code in block >> headers which occurred before the checks on code evaluation?)? > > No, we can't. But it is true for any software that allows third-party > code, not just for Org or even Emacs. > Yes, you are right there are no guarantees. However, I do feel that if we are going to add this security layer, we also need to perform some form of audit and documentation of the specific points where org constructs will/can trigger evaluation of included code. As the bug with rich text demonstrated, there will likely be corner cases we miss. However, we should at least try to identify as many as possible and document them (and include automated tests when possible). One of the downsides regarding improved security controls is that it raises the level of expectations. We need to try and ensure we meet those expectations. What we really need are some good ethical hackers to help us identify potential 'hot spots'. The ability to do this effectively does involve a particular type of mind set and skills not necessarily common amongst most users. > And we cannot use the more universal sandbox approach either. Not in > Emacs. > >> It also feels like the approach we have taken here is almost a throwback >> to a past era where he had a lot more trust. What we seem to have is >> protection against accidental execution of code rather than protection >> against code with malicious intent which has been crafted to be >> difficult to spot and deliberately takes advantages of small 'holes' or >> over-sight in the controls supplied. > > I do not think that we can do anything about crafted code in Emacs other > than displaying that code and letting the user decide. > Agreed. What we need next is the ability to track those decisions so that the user isn't nagged about the same things every time and the ability to set different defaults based on some preference (such as source/origin, location, etc. > And I haven't seen any better solution, except anti-virus scanners that > are constantly fighting new malicious code. > > At least, we do show the code. It is already better than "yes/no" > dialogue you get when running random executable on Windows. Agree. The question is whether we actually do provide that y-n and display in sufficient situations. Given the additional information you provided, I'm somewhat less concerned. These 'knobs' definitely do need some form of additional abstraction which will more easily allow end users to set a basic policy regarding the treatment of different org files or org files from different sources. I suspect, in the long-term, we are likely to need some type of file 'cookie' i.e. a local-variable setting which will either set the policy for that file or set the origin/source/trust level etc so that whatever security policy the user has defined can be applied. IN some ways, similar to the 'cookie' placed into your custom variables when you say you trust some new theme.