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 wGaiBLnSqWK3qQAAbAwnHQ (envelope-from ) for ; Wed, 15 Jun 2022 14:38:17 +0200 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 MH+NBLnSqWJfEAAA9RJhRA (envelope-from ) for ; Wed, 15 Jun 2022 14:38:17 +0200 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 C391F150C for ; Wed, 15 Jun 2022 14:38:16 +0200 (CEST) Received: from localhost ([::1]:38298 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o1SHn-0002pe-Pb for larch@yhetil.org; Wed, 15 Jun 2022 08:38:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59960) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o1SFX-0002k1-5D for emacs-orgmode@gnu.org; Wed, 15 Jun 2022 08:35:55 -0400 Received: from ciao.gmane.io ([116.202.254.214]:57068) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o1SFV-0006H2-5u for emacs-orgmode@gnu.org; Wed, 15 Jun 2022 08:35:54 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1o1SFR-0003yQ-DN for emacs-orgmode@gnu.org; Wed, 15 Jun 2022 14:35:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: [PATCH] New remote resource download policy Date: Wed, 15 Jun 2022 19:35:41 +0700 Message-ID: References: <87mteiq6ou.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Content-Language: en-US In-Reply-To: <87mteiq6ou.fsf@gmail.com> Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 28 X-Spam_score: 2.8 X-Spam_bar: ++ X-Spam_report: (2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no 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" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1655296696; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=ZdpB857UGPBhROdPaq+Q8j5jWMp3TKpogwmjuydVBtk=; b=FzMb3w9eIESuL7aKTVkrLODNDz1qrjyPo8Tn8VoAC0Fv+uPvm3RrVpfPrUCXHUhHMRkp+1 ewVGUa+lnjURG4PN/s1hpizO+rLa169CK+n5UAM9Tu4f60R3zouQW8aL764rK8YwLJzGqG zzOPitkecob7HQ797flXbWpZWL5xiXgyWKy8k7tJ5oT1pzvntaYWi6+Z9ixLkbJvR4e0RW TYitCL5YI20qdfdnHsdxsaAxUwm6pReXYfXDCxnTb+NTqx6B+oUlepYo85ZRCrYoC9/9CT EK5kWc0vAZdHMDv2Jo6F6cSw4O5bOmtqWiPaD7Z8T9Xi17v0/+69LJZTH2ke6Q== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1655296696; a=rsa-sha256; cv=none; b=JpozWazAgx3kZP3Z+P4Qn2UcGlfCkJQQg96Bo1QNSAO2cGrT7q23xZxUFfWEKPeXwILefk S8Ru5DCqndoH/BNt7spJ6zbiq7wspEy4aCEQ/Xnfi7Rcru5wL/zh15ZP31FFVRp7IV+UQl tluCL/bicnSRQYj9d79G4Awl3DY19hvaEJ39ipjcAxUXuNWrQPM1NeuGy08l1T4AqIPCgF nF9eYy8cyfEGlU7xsibx/Yf2n9HR8FjHYgHRsyZdlPpFwGZg8u4eyz45hMcX53Z9XOkdHr T7rK24gGsprCDKFvvIexj27ye9JtKAhIVAnwWbaw+n5dD/VD6C2FQioJO0qSSA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); 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: 2.71 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); 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-Queue-Id: C391F150C X-Spam-Score: 2.71 X-Migadu-Scanner: scn1.migadu.com X-TUID: i+om9Uf6zdMv On 12/06/2022 21:43, Timothy wrote: > > As was raised in the #+include: URL thread > (https://list.orgmode.org/877d5sd7yu.fsf@gmail.com), currently Org will > automatically download files without confirmation in various circumstances. > > This patch introduces two variables to control Org’s attitude towards > downloading files, and hooks them into the relevant parts of the codebase. Timothy, thank you for efforts in this direction. In some sense you have done even more than I asked for. I tried you patch mostly to confirm that the protection can not be bypassed using file local variables. Since custom variables are not marked as safe, user is asked if values should be applied. Such behavior is consistent with my expectation. > --- a/lisp/org-attach.el > +++ b/lisp/org-attach.el > @@ -525,7 +525,11 @@ (defun org-attach-attach (file &optional visit-dir method) > ((eq method 'cp) (copy-file file attach-file)) > ((eq method 'ln) (add-name-to-file file attach-file)) > ((eq method 'lns) (make-symbolic-link file attach-file)) > - ((eq method 'url) (url-copy-file file attach-file))) > + ((eq method 'url) > + (if (or (not noninteractive) (org--should-fetch-remote-resource-p file)) I am confused by (not noninteractive). Does it mean that interactive call is enough to bypass protection? It may have sense it at this step there is no ambiguity what resources is fetched. On the other hand I am unsure concerning a case when `org-attach-attach' is a part of a larger command. > + (url-copy-file file attach-file) > + (error "The remote resource %S is considered unsafe, and will not be downloaded." > + file)))) > +(defcustom org-download-remote-resources 'prompt The name sounds like some function. > +(defun org--confirm-resource-safe (uri) > + "Ask the user if URI should be considered safe, returning non-nil if so." > + (unless noninteractive > + (let ((buf (get-buffer-create "*Org Remote Resource*"))) I see your intention to add something fancy to the dialog. May `org-mks' be reused instead to avoid proliferation variants of rather similar UI code? > + ;; Set up the contents of the *Local Variables* buffer. > + (with-current-buffer buf > + (erase-buffer) > + (insert "An org-mode document would like to download " > + (propertize uri 'face '(:inherit org-link :weight normal)) > + ", which is not considered safe.\n\n" > + "Do you want to download this? You can type\n " > + (propertize "!" 'face 'success) > + " to download this resource, and permanantly mark it as safe.\n " > + (propertize "y" 'face 'warning) > + " to download this resource, just this once.\n " I am in doubts concerning "once". I tried "y" in a file having to "#+include:" of the same file. I did not get question for second include. I did not get prompt for this file anymore at all, even during next export. I modified the remote file, but stale content appeared during export. So the file was really downloaded once, but it is hardly in agreement with my expectations. Behavior is unrelated to this patch, concerning wording I am not sure, but I have no a better variant. > + (propertize "n" 'face 'error) > + " to skip this resource.\n") From "skip" I do not expect aborting of export. I have an idea but unsure if it should be implemented. Consider `org-remote-resources-policy' custom variable that is a list of pairs (url-regexp . policy) for fine grain tuning instead of 2 variables. The price is more complicated structure, so higher chance of user error.