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 MG94Aa8dq18uDgAA0tVLHw (envelope-from ) for ; Tue, 10 Nov 2020 23:09:35 +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 IPLcOK4dq19pdgAAbx9fmQ (envelope-from ) for ; Tue, 10 Nov 2020 23:09:34 +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 8EBFF9404E0 for ; Tue, 10 Nov 2020 23:09:33 +0000 (UTC) Received: from localhost ([::1]:44798 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kcclX-0005qX-2P for larch@yhetil.org; Tue, 10 Nov 2020 18:09:31 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47734) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcckg-0005oo-SC for emacs-orgmode@gnu.org; Tue, 10 Nov 2020 18:08:38 -0500 Received: from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d]:38441) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kcckf-0002cd-2n for emacs-orgmode@gnu.org; Tue, 10 Nov 2020 18:08:38 -0500 Received: by mail-wm1-x32d.google.com with SMTP id h62so4919523wme.3 for ; Tue, 10 Nov 2020 15:08:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nY68EW5rpo8xmv06IStdJEWa810WlqV3f6odCWX6ZDU=; b=HzmRauvO84DfuFQsEzx/rxqENfhshqOnB2ItZUIx5qzbpmb2pdfvUWmynf8Cj0yjAJ KnLD7r0KL4wJ4zYq6MqmrvSetZRf3yeNWMQDcYpnRIQlFMKNWfC1DQmmMTzkzIvaKeq0 tlEY37V68n2WwNE3QWv0N96eCc1sxWYkKkVH/Ip5rXeVhfTHkC/XGVwWrWIdG4CGqvvG viGNuMH4P7WpWwEvsMi/CT10fwlNn3412KCWsC//kVig9+rI8HQS+JZEWCTIcEF8HrZE OvCzZBvAsHEGC2YJ1AfzWec7pd9wbI+RjJLQF996BVfi1I430ZRc5SZc52QZoh6fxJHR gAtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nY68EW5rpo8xmv06IStdJEWa810WlqV3f6odCWX6ZDU=; b=d93mlvs4s2BkXhhHkVCLYpOqvkTBxEe+tqIQL5cbz3ySuCs6a6LDx8eP/UpaCsmue6 Ik42cx7t6XSf/RHjHv1MggcXW/qoDx6Aldhczo+MZFoFtdK8/teQgn4za5upoD7LiRqC AvgwknxT/JZVm0qUvzO1MZt5TuVxGESMtmZDP7pQ0oBTRa40ey0TxrjjhC8LIyrgXtNh OrhIdUBzbqQodki9FFOZv63cEHPx+f0YYNdg0aVWMWvcZWefpN3AVJciKdwhvfA8xlsb b6EtAxkdfuBFLpcGhpyC8VL3nefxzDwi06gWGPdfuqwZDaPUXRjlNQIkNWD+8vhpa8xX Pf9Q== X-Gm-Message-State: AOAM530g8fVpg/ykuAOkZiTGiEp761Lr5UOFalsuvlqV2IcefsVm/gkd /C6Wz8nBnCjx2B5Z4xkZqpsQka41vANLfRShjQM= X-Google-Smtp-Source: ABdhPJypQ4XLrN68qxFPiUv+h48WsrV7kE/qKIQuftiazS2dKbdCzcJyGudI7rOfuCt27wuT2a10x1BLR4BdGipmOPw= X-Received: by 2002:a1c:1b85:: with SMTP id b127mr440482wmb.163.1605049714777; Tue, 10 Nov 2020 15:08:34 -0800 (PST) MIME-Version: 1.0 References: <20201101161317.GA6609@maokai> <87imaoekrz.fsf@web.de> <39fb1f8d-4407-9359-ad14-72ae7841fda9@grinta.net> <87tuu85djy.fsf@gmail.com> In-Reply-To: From: Tom Gillespie Date: Tue, 10 Nov 2020 18:08:22 -0500 Message-ID: Subject: Re: Thoughts on the standardization of Org To: Maxim Nikulin Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::32d; envelope-from=tgbugs@gmail.com; helo=mail-wm1-x32d.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: , Cc: emacs-orgmode 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=HzmRauvO; 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: +4wup7JVM5SR 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!). Best! Tom