Re: [PATCH] New remote resource download policy

[Max Nikulin]

On 22/06/2022 17:01, Timothy wrote:
> > > — a/lisp/org-attach.el
> > > +++ b/lisp/org-attach.el
> > > @@ -525,7 +525,11 @@ (defun org-attach-attach (file &optional visit-dir method)
> > > [snip]
> > > +        (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.
>
> The idea here is that when this is done interactively the user will be aware of
> the URL this is being applied to, and so it isn’t a risk. Let me know if this
> assumption doesn’t hold.

I am not sure what is the best option here. Despite `org-attach-attach' 
is an interactive command, URL code path most likely will be followed 
when this function is called from another one. *Currently* my opinion is 
that it is caller who is responsible for the decision whether the user 
explicitly asked for a particular resource so it may be considered safe. 
For example for `org-attach-url' probability that it is called by user 
directly is higher than it happens from another function.

So I am considering such variant: no heuristics is added to 
`org-attach-attach', but `org-attach-url' temporary adjusts the list of 
safe locations to bypass user prompt. Notice that I am not an active 
user of `org-attach'.

> > > +(defcustom org-download-remote-resources ’prompt
> >
> > The name sounds like some function.
>
> Mmm. I could add `-policy' to that variable name perhaps.

It will be too long. Maybe org-remote-resources-policy, but I am leaving 
the decision up to you.

> > > +(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?
>
> Well, the thing here is that I’m explicitly trying to mimic the
> file-local-variable dialog, and since a general form isn’t exposed by Emacs, a
> little bit of proliferation seems like the best option to me.

I do not have strong opinion, I provided an example of `org-mks' reusing 
in another message.

> > > +                  (propertize “n” ’face ’error)
> > > +                  “ to skip this resource.”)
> >
> >  From “skip” I do not expect aborting of export.
>
> Hmm, the “skip” action isn’t determined by the “is it safe” functions, but some
> wording that doesn’t sound completely safe at least would be good.

At least for export it works more like "Abort".

I have realized that e.g. 7zip, asking if it should overwrite an 
existing file, offers "Always" variant. Almost certainly I saw similar 
buttons in other dialogs on Windows as well. Unsure it it may be easily 
implemented, but the case "Allow all remote URLs for the current file" 
sounds like a valid option during export.