From: Max Nikulin <manikulin@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: [PATCH] New remote resource download policy
Date: Sat, 25 Jun 2022 14:50:43 +0700 [thread overview]
Message-ID: <t96eok$air$1@ciao.gmane.io> (raw)
In-Reply-To: <87pmj1nh7v.fsf@gmail.com>
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.
prev parent reply other threads:[~2022-06-25 7:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-12 14:43 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
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 [this message]
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
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='t96eok$air$1@ciao.gmane.io' \
--to=manikulin@gmail.com \
--cc=emacs-orgmode@gnu.org \
--subject='Re: [PATCH] New remote resource download policy' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox:
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
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).