emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Max Nikulin <manikulin@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: [PATCH] New remote resource download policy
Date: Wed, 15 Jun 2022 19:35:41 +0700	[thread overview]
Message-ID: <t8cjmu$du6$1@ciao.gmane.io> (raw)
In-Reply-To: <87mteiq6ou.fsf@gmail.com>

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 

> +            (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.

  parent reply	other threads:[~2022-06-15 12:38 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-12 14:43 [PATCH] New remote resource download policy Timothy
2022-06-12 16:18 ` Daniel Fleischer
2022-06-14  9:40 ` Robert Pluim
2022-06-22  9:58   ` Timothy
2022-06-15 12:35 ` Max Nikulin [this message]
2022-06-22 10:01   ` Timothy
2022-06-22 16:55     ` Max Nikulin
2022-06-29 15:27       ` Timothy
2022-06-30 16:57         ` Max Nikulin
2022-07-16  9:47           ` Timothy
2022-06-25  7:50     ` Max Nikulin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='t8cjmu$du6$1@ciao.gmane.io' \
    --to=manikulin@gmail.com \
    --cc=emacs-orgmode@gnu.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).