From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.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 8lf+DLwknGNXSQAAbAwnHQ (envelope-from ) for ; Fri, 16 Dec 2022 08:56:44 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id UKCvCrwknGOtZAAA9RJhRA (envelope-from ) for ; Fri, 16 Dec 2022 08:56:44 +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 B78C428CB4 for ; Fri, 16 Dec 2022 08:56:43 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p65ZV-0006zz-Rf; Fri, 16 Dec 2022 02:55:57 -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 1p65ZS-0006zo-Po for emacs-orgmode@gnu.org; Fri, 16 Dec 2022 02:55:54 -0500 Received: from mail-pf1-x436.google.com ([2607:f8b0:4864:20::436]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p65ZR-0005Sm-2W for emacs-orgmode@gnu.org; Fri, 16 Dec 2022 02:55:54 -0500 Received: by mail-pf1-x436.google.com with SMTP id k79so1244600pfd.7 for ; Thu, 15 Dec 2022 23:55:52 -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=x4Rx/9p/Li15sxpVS7QI64SA+w02PfRHBVP+mpfBjNg=; b=SLxH765i7mw85fUrY4sRki9IYy8QHRnC3S1QeChFtLlDe6g/dnj0mppdEw5KmOiffc GG5Z3KoXyOPuDNOtHYl2RMnd313D/n554fL6QkVRj4NEQPe80P3CgpHJ//IBr2Ykq61+ rnUXsZBZJX5+KzLXJW2kzAAUvXUFy/37IRkafojrBNC9eNnwVqaT3jHADXNMk0P8MzPK qe16dugcBrb1Z1qrWJ1jhOBWFgq+Sa3ka71BxXOCbv93A+b89GN3ihTjYTCzVwjToUuu lmWv5lNONJnWZsONiCxTGpn5arn7HGz1IyZTl4LLGJwATvzkH2RKnI9Cl2PgwNLTtcXg YGdA== 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=x4Rx/9p/Li15sxpVS7QI64SA+w02PfRHBVP+mpfBjNg=; b=fQCIzSBnQW32v0e8+ser4Jom06c2u0y7PycZvxZ802TBNLxxzcDXXAy2w39B5PYLbW 7kbEgfaApdz3DwS5dKXXQ8r7iR17qtMBihy1zL/3S2L3zChmQSCNNTziig6oE/dWuQDh /lIPfFrvfEuTwYshZDY4+/LMDVdb9BHIwzkbNhgdKAmMXZQc1yZReWqfke9E/DERDDAa ZBoXe9Rn5YYziSlKXK+S0VhPd+X3lkaEvOnDVDAylc3SZYcArEba9EU+kjDbJn0wTGmk EmSwH8SEB96VuWGzpREibC3GUf0SYc40+X/86T/9IKsye8mmYLDsM67trWSODqOWq1CI YbLg== X-Gm-Message-State: ANoB5pnmnTLN1wgh9JUwSyC6MXdQnlDRBAqXfgeGmrXJZe2FbdiuGCT5 mLxavys/TdY2XQDykLh50sJBLsw74+Y= X-Google-Smtp-Source: AA0mqf6JuWyC8t7TeKUVbSAweGumvmCsGURfb854W90efyijVpFIpsR8K+GlpdktgPjq7SGIAae5XA== X-Received: by 2002:a05:6a00:1d04:b0:578:8533:9573 with SMTP id a4-20020a056a001d0400b0057885339573mr17852788pfx.22.1671177351222; Thu, 15 Dec 2022 23:55:51 -0800 (PST) Received: from dingbat (203-173-24-107.dyn.iinet.net.au. [203.173.24.107]) by smtp.gmail.com with ESMTPSA id t13-20020a62d14d000000b00578199ea5afsm852262pfl.9.2022.12.15.23.55.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Dec 2022 23:55:50 -0800 (PST) References: <87359ld5ye.fsf@kyleam.com> <874ju0j538.fsf@localhost> <87len9uj5s.fsf@localhost> <87ilicua53.fsf@localhost> <86len8uxmu.fsf@gmail.com> <87o7s3swyt.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: Fri, 16 Dec 2022 18:22:26 +1100 In-reply-to: <87o7s3swyt.fsf@localhost> Message-ID: <86h6xvvl30.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::436; envelope-from=theophilusx@gmail.com; helo=mail-pf1-x436.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=1671177403; 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=x4Rx/9p/Li15sxpVS7QI64SA+w02PfRHBVP+mpfBjNg=; b=gwDjZBZNa4mlpREHWmPlqsPLgLIsFOIhsrWcHNU1SFYLyStdS+7FNfdO6xtrWdqM6K/g1d 2UkdpuHVJ/uXGmBHv1JXUpM2wgG+D3KRuAXfjv2p3VomCJRhfgNshoozFPeDI8O/Yuoyxa 5yQ1ezB+U7NiWWJOit2RPTw5Mw1GIdvMAu/1LB7jbzTzwUPsInsMXpcc0c4nZJmjaLC8Rc YNbyLhZjjILMcTlRvv4y83RyuBSJy8NqRIdd/iUkN1njhbPCk3r5FaLp7KoFX7QM+Uy73j 3nXirz6nzNWYF7xj2J9vIa16+0iH8fvC/HD2luPEHJubG+JdWY19xAgxofYIow== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=SLxH765i; 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=1671177403; a=rsa-sha256; cv=none; b=Vgneih6b7xqQSGo9C9HcZjkOpE6RNpbYDggq+cTgBmxc3repKAnuAxHxMm8m1hcZxSg9tb 0K3po+Rshl6PuZ7HGsL6BUYmSFRRMhsT6fs5FhuBzQCob2DB2DtVQOJklgL9COTB9pSdyr HkRGuuBn8v+tDiajDDK6OgxFwqULZxNBqd1QKrzQAXUGC3u+mawP6/ls7VY5fZjrppPRKu pZx0whtrkvtC6HVIU1qREwDKrSu9hur7iF7Q55H0U/31fl6mLid5pD4hFuNZWFY1cDpKpq /WZ2S6+a/hyodg43vjR3id+hzdeoCaigkpL7/XPw89BFwseGGf8ymMu/080Aug== X-Spam-Score: -5.96 X-Migadu-Queue-Id: B78C428CB4 X-Migadu-Scanner: scn1.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=SLxH765i; 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: -5.96 X-TUID: ObVAp5gYkggj Ihor Radchenko writes: > Tim Cross writes: > >> 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. > > 17.13 Code Evaluation and Security Issues That page is a good start. However, I think it highlights why not having a clear model limits the utility of the options being provided. Consider this scenario - I am a reasonably experienced Emacs user, but wouldn't describe myself as proficient with elisp. I can do some basic stuff and I have an init.el file which I basically understand, although there are some borrowed bits which to be honest, I don't fully understand. I use org mode a lot. I really like literate programming and find the whole babel stuff really cool. I also make extensive use of tables and the spreadsheet capability to track statistics on my projects and use gnuplot, ditta and plantuml to generate plot, diagrams etc from that data. Obviously, I trust all the code in these files as I wrote it! On occasion, I get org files from colleagues. While I do basically trust my colleagues, I don't want to just blindly allow execution of the code in these files. I would like to check what the code does before agreeing to allow it to run. On very rare occasions, I get an org file from an untrusted source. In this situation, I want iron clad assurances none of the code from this file is executed. 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. How does this fictitious user achieve this configuration? Is it a reasonable expectation that most users will be able to write the elisp necessary to achieve this model? 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. 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?)? 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.