From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id LoZXAQAqq1+FbQAA0tVLHw (envelope-from ) for ; Wed, 11 Nov 2020 00:02:08 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id gJxBOP8pq19BGwAAbx9fmQ (envelope-from ) for ; Wed, 11 Nov 2020 00:02:07 +0000 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 501D09403CA for ; Wed, 11 Nov 2020 00:02:07 +0000 (UTC) Received: from localhost ([::1]:53918 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kcdaO-0006KP-Ns for larch@yhetil.org; Tue, 10 Nov 2020 19:02:04 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:58732) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcdZO-0006K8-Vv for emacs-orgmode@gnu.org; Tue, 10 Nov 2020 19:01:03 -0500 Received: from mail-pg1-x533.google.com ([2607:f8b0:4864:20::533]:33466) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kcdZL-000090-N8 for emacs-orgmode@gnu.org; Tue, 10 Nov 2020 19:01:02 -0500 Received: by mail-pg1-x533.google.com with SMTP id r186so166427pgr.0 for ; Tue, 10 Nov 2020 16:00:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:subject:in-reply-to:message-id:date :mime-version; bh=LCofMzQLbnLzKolwfjGWxOJiErYEcbcv0YKwALghtv4=; b=gx1a90RYD4BiJw1ql3p8TUPoaNsdVy5DA8LVyr3ilotNrQzopXZgqijUIUkql19pxe DCUD5kMxbqAltNszY0U6T1huGrHZBwVbRVssoyGp7nr6CVfJjW1HNUmxG+FmhoRt5Jo2 /INAnwo5NBKIPBUFPhklpChSH5IEbJsSMExhjw638hX+8kxN875aW6dRj4um83jwVNxm 8cRVekvNhEzGgG+tQ/U9sBftNMfOk+8S7o80HPXSpxMVIWf3QXRiVFgoi8othWu2KaGP WrVvix5ZETGjjc0W2AGn/7hHsI2bZ9XoXvqvh+QMBEgGjwWyiRqxJ8WP4CrNwMaoBKec SBNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:subject :in-reply-to:message-id:date:mime-version; bh=LCofMzQLbnLzKolwfjGWxOJiErYEcbcv0YKwALghtv4=; b=jQstRTNW9JpMfz3cVIjSV0HlkFAOkxvheYRWvAxVcnxhnj9BKTXtE1E12sDtTpETF1 cbxwR5rqJ5dg0/FiuCCaV2fOZbCC1CV5QyAcjjuglBxjKQF8OGd8Ecur65SogpC1+SQi B2z1JBIP7aFYGv5aVVNpG9s76lUAVmdtcJlFAmNInxnKNX8+L6ANGMAwpWNhPHHG8CjL wegc9evjExPmBiEz/YckgH+lJlKxPXQKJL88frDLjYw8aQNG222QCTqT66TpnF5iySvI YLoW8GLDCa8Rm1V4MU+VWuxmHuNc+yQYhoJy5buIB3qFhRs8aiOkYN2hOmc+DYLp41uo NTpQ== X-Gm-Message-State: AOAM530ytm4z8yzkQ9h+aPYNJcN+R0e3CnBF5GjukrzE8UcDrqHvxUac OMOnyGGcINhVhaJii7diB/7ZIkzCnI4Frg== X-Google-Smtp-Source: ABdhPJyG5xx80mMChcLJ5/MTuxxfP3ZMnRyUBUiQq6JFCynf6g7971yWEr5WhOU8VcphKDpA57Lx9g== X-Received: by 2002:a63:6243:: with SMTP id w64mr18739009pgb.430.1605052857749; Tue, 10 Nov 2020 16:00:57 -0800 (PST) Received: from tim-desktop (106-69-81-190.dyn.iinet.net.au. [106.69.81.190]) by smtp.gmail.com with ESMTPSA id a123sm249550pfd.218.2020.11.10.16.00.56 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Nov 2020 16:00:57 -0800 (PST) References: <20201101161317.GA6609@maokai> <87imaoekrz.fsf@web.de> <39fb1f8d-4407-9359-ad14-72ae7841fda9@grinta.net> <87tuu85djy.fsf@gmail.com> User-agent: mu4e 1.5.6; emacs 27.1.50 From: Tim Cross To: emacs-orgmode@gnu.org Subject: Re: Thoughts on the standardization of Org In-reply-to: Message-ID: <87v9ecwymh.fsf@gmail.com> Date: Wed, 11 Nov 2020 11:00:54 +1100 MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::533; envelope-from=theophilusx@gmail.com; helo=mail-pg1-x533.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. 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.23 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-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=gx1a90RY; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: -0.21 X-TUID: vrvD3YmcXv17 Tom Gillespie writes: > This is a great sub-thread that should probably be its own top level > thread on org security. > > Org files are mostly benign unless the user does something extremely > dangerous like > setting enable-local-eval t. However, there are some areas where > arbitrary code can be > executed (as intended) that some users may not be aware of. Consider > the following. > > #+begin_src elisp :var lol=(message "If I were evil I could use > call-process here to give you nasal demons") > #+end_src > > When is the closure for the variable lol evaluated? The most obvious time is if > you run the block. The less obvious time is if you run org export! > > More subtly. > > #+name: some-block > #+begin_src elisp > #+end_src > > #+call: some-block() :var pwnd=(message "oops!") > > When will the closure for pwnd be called? When exporting it happens before > you receive the prompt asking whether you want to execute some-block! > Very easy to fool someone who doesn't know how top level closures work > into goofing on that one. Furthermore even when a file also sets > > #+property: header-args :eval no-export > > then the closure will still be evaluated! > > Or how about > > Running org export can execute arbitrary code even if you decline to run blocks > or set default header-args in your config. This means that it is not safe to, > for example, run a public server that transforms arbitrary org files into pdfs. > > How about some more fun? > > #+name: some-block > #+begin_src elisp :tangle ./itsatrap.el :dir (message "OH NO") > #+end_src > > Yep. That does what you think it does. If you tangle the file, arbitrary code > execution. No tangling files from strangers either. > > The examples I present here do require user input to fire off the process, > it won't happen without them doing something but it is much easier to > C-c C-e h h or C-c C-v t when you are an expert user, so you have to > be careful. Sharp tools. > > Despite these examples, the ability to define values using arbitrary closures > is one of Org's most powerful features. > > In the context of standardization, this suggests that it might be nice to > have a dynamic variable that controls whether bare closures will be > evaluated (one might already exist, I have no idea), along with a spec > that says what the failure modes should be if one is encountered that > cannot be evaluated. > > In the context of org generally, maybe that variable could also be used like > org-confirm-babel-evaluate and take a function as an argument, ask if t, don't > ask if nil, or ask only if result is t (or was it nil ... regardless match > org-confirm-babel-evaluate). org-confirm-closure-evaluate maybe? (Again if > this already exists, then woo!). > Another one, which I think is even a little more subtle, is table formula evaluation. Using the advanced features of tables, you can define a table that will automatically run formulas (which could be a calc expression OR an elisp function) when you navigate through a table, such as by hitting tab to move to the next column. I imagine this is something you could easily do as tabbing through a table is a convenient way to browse the contents. While by default, org is pretty good, the real risk is that I suspect many will have tweaked the evaluation settings - I know I have and while I would not evaluate or export anything in an org file I was sent until I had assessed it, mistakes do happen and I could easily hit C-c C-c in the wrong context and cause a block to be evaluated without any prompting for confirmation. Given the complexities of dynamic content evaluation in org, perhaps a simple solution would be to add a special MIME handler function which would open an org file in a restricted mode, ignoring user settings affecting code evaluation and preventing any form of evaluation, even if the user asks for it. Basically, allow viewing, folding, navigation of the org file, but no evaluation. If the user wants to export or tangle or update tables etc, they would be forced to save the file and then re-open it as a normal org file. It would be this handler function you would configure in your MIME types as the function to run to view an org attachment etc. You could take it one step further an allow the definition of a 'tursted senders' list. When opening an org attachment, this list is checked and if the sender is in the list, normal org open process is applied, otherwise the restricted MIME open function is applied. This would be similar to the Gmail approach for handling images. -- Tim Cross