Re: [BUG] Unsolicited download of remote resources

[Ihor Radchenko]

Max Nikulin  writes:

>> [...]> The prompt is displayed twice because fetching is attempted twice 
>> - when
>> reading startup options and when initializing macros. This is
>> sub-optimal, but expected.
>
> Are names of macros necessary for some purpose before export is started?

With the current implementation of `org-get-title', yes.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] Unsolicited download of remote resources

[Max Nikulin]

On 03/02/2024 03:03, Ihor Radchenko wrote:

Max Nikulin writes:


#+setupfile: http://localhost:8000/setup-1234567890.org

I am trying to decline attempts to download the remote resource by
hitting "n" (skip), but Org still tries to fetch that file and does it
twice. I see in the *Messages*
[...]> The prompt is displayed twice because fetching is attempted twice 
- when

reading startup options and when initializing macros. This is
sub-optimal, but expected.


Are names of macros necessary for some purpose before export is started?

Re: [BUG] Unsolicited download of remote resources

[Ihor Radchenko]

Leo Butler  writes:

> So, it is *possible* to have the setupfile set-up arbitrary elisp code
> that would be evaluated at some later time (during export or src block
> evaluation, as you wrote)? Is that correct?

Yes. That's why we prompt when SETUPFILE is remote.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] Unsolicited download of remote resources

[Leo Butler]

On Mon, Feb 05 2024, Ihor Radchenko  wrote:

> Leo Butler  writes:
>
>> Q: if #+setupfile points to a real file available to download, does Org
>> evaluate that file?
>
> keywords and startup options are taken from there. No Elisp code present
> in #+SETUPFILE is evaluated.
>
> That said, if the file defines babel header arguments with elisp or
> "eval" macros, they may be used later, during export or when src block
> evaluation is requested by the user.

So, it is *possible* to have the setupfile set-up arbitrary elisp code
that would be evaluated at some later time (during export or src block
evaluation, as you wrote)? Is that correct?

Leo

Re: [BUG] Unsolicited download of remote resources

[Ihor Radchenko]

Leo Butler  writes:

> Q: if #+setupfile points to a real file available to download, does Org
> evaluate that file?

keywords and startup options are taken from there. No Elisp code present
in #+SETUPFILE is evaluated.

That said, if the file defines babel header arguments with elisp or
"eval" macros, they may be used later, during export or when src block
evaluation is requested by the user.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] Unsolicited download of remote resources

[Leo Butler]

On Sun, Feb 04 2024, Max Nikulin  wrote:

> On 03/02/2024 02:04, Leo Butler wrote:
>> When I opened your email in Gnus, I was greeted with the same
>> (bewildering) message. Given that Org still tried to download the
>> setupfile after being told not to, I think this is a majour security
>> hole.
>> This is also related to another thread concerning Org and email.
>> https://list.orgmode.org/orgmode/87cyteyhif.fsf@localhost/
>
> Sorry for sending a message with this kind of attachment, but from the
> discussion of that Emacs bug I expected that almost no Gnus users
> should be affected since their media type handler is set for
> text/x-org while Thunderbird uses "Content-Type: text/org".
>
> I would not classify this kind of issues as security ones. I am
> unaware of Org features that may make content of "#+setupfile:" more
> dangerous than the same snippet is included into attachment
> directly. (OK, antivirus might have a chance to detect something as
> dangerous code and "#+setupfile:" would bypass such protection.)
>
> I consider it as a privacy issue. It may allow spammers to track if
> their messages are delivered successfully.

There's no need to apologize--I was surprised at the whole episode.

Q: if #+setupfile points to a real file available to download, does Org
evaluate that file?

Leo

Re: [BUG] Unsolicited download of remote resources

[Ihor Radchenko]

Max Nikulin  writes:

>> Please confirm that the fix works on your side.
>
> I have tried it with this specific scenario: open such a file (not a 
> mail message with an attachment) with http: URIs. "Skip" works as 
> expected now. I am unsure if any kind of remote files is blocked.

Thanks for checking!
Released as a part of Org 9.6.18.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] Unsolicited download of remote resources

[Max Nikulin]

On 03/02/2024 02:04, Leo Butler wrote:


When I opened your email in Gnus, I was greeted with the same
(bewildering) message. Given that Org still tried to download the
setupfile after being told not to, I think this is a majour security
hole.

This is also related to another thread concerning Org and email.
https://list.orgmode.org/orgmode/87cyteyhif.fsf@localhost/


Sorry for sending a message with this kind of attachment, but from the 
discussion of that Emacs bug I expected that almost no Gnus users should 
be affected since their media type handler is set for text/x-org while 
Thunderbird uses "Content-Type: text/org".


I would not classify this kind of issues as security ones. I am unaware 
of Org features that may make content of "#+setupfile:" more dangerous 
than the same snippet is included into attachment directly. (OK, 
antivirus might have a chance to detect something as dangerous code and 
"#+setupfile:" would bypass such protection.)


I consider it as a privacy issue. It may allow spammers to track if 
their messages are delivered successfully.


I was really surprised when I found "n" option to decline downloads 
broken. I expected it was addressed in
[PATCH] New remote resource download policy. Sun, 12 Jun 2022 22:43:07 
+0800. https://list.orgmode.org/87mteiq6ou@gmail.com

since it was risen in the earlier thread
[PATCH] Support =#+include=-ing URLs. Sun, 05 Jun 2022 22:32:30 +0800.
https://list.orgmode.org/87k09v5gap@gmail.com

Re: [BUG] Unsolicited download of remote resources

[Ihor Radchenko]

Max Nikulin  writes:

> However it may be unclear for users that setting `t' for 
> `org-resource-download-policy' is dangerous if they use Emacs as a mail 
> client or as a handler for opening links to .org files in browsers. I 
> would consider adding "dangerous" to the label of this option and a 
> warning to the docscring.

Would you be interested to submit a patch?

> Another my concern is an attack using an attachments with multiple 
> "#+setupfile:" keywords with remote URIs. Users will be tired declining 
> specific download requests without an option to ignore all remote 
> resources. I hope, C-g it is obvious enough and it works in gnus I 
> am unsure how to implement in Emacs an approach used e.g. in 
> Thunderbird. Remote content is blocked till an explicit user action and 
> a yellow bar with an unblock button is displayed at the top of the 
> message body pane.

I am not in favor of creating such new interface as a part of Org mode.
You can propose it to Emacs upstream. If they are interested, it is
something we may consider. However, there have been multiple discussions
about delayed prompts in the context of async ELisp evaluation - AFAIR,
such ideas were not welcome on the grounds that such prompts may be
missed by the users.

What we can do is adding a new answer - "N" aka "no for all for the
duration of current command".

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] Unsolicited download of remote resources

[Max Nikulin]

On 03/02/2024 03:03, Ihor Radchenko wrote:

Max Nikulin writes:


--- 8< ---
#+setupfile: http://localhost:8000/setup-1234567890.org

test
--- >8 ---

[...]

Fixed, on bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=56748ea4e

Please confirm that the fix works on your side.


I have tried it with this specific scenario: open such a file (not a 
mail message with an attachment) with http: URIs. "Skip" works as 
expected now. I am unsure if any kind of remote files is blocked.


However it may be unclear for users that setting `t' for 
`org-resource-download-policy' is dangerous if they use Emacs as a mail 
client or as a handler for opening links to .org files in browsers. I 
would consider adding "dangerous" to the label of this option and a 
warning to the docscring.


Another my concern is an attack using an attachments with multiple 
"#+setupfile:" keywords with remote URIs. Users will be tired declining 
specific download requests without an option to ignore all remote 
resources. I hope, C-g it is obvious enough and it works in gnus I 
am unsure how to implement in Emacs an approach used e.g. in 
Thunderbird. Remote content is blocked till an explicit user action and 
a yellow bar with an unblock button is displayed at the top of the 
message body pane.

Re: [BUG] Unsolicited download of remote resources

[Ihor Radchenko]

Max Nikulin  writes:

> --- 8< ---
> #+setupfile: http://localhost:8000/setup-1234567890.org
>
> test
> --- >8 ---
>
> I am trying to decline attempts to download the remote resource by 
> hitting "n" (skip), but Org still tries to fetch that file and does it 
> twice. I see in the *Messages*

Fixed, on bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=56748ea4e

Please confirm that the fix works on your side.

The prompt is displayed twice because fetching is attempted twice - when
reading startup options and when initializing macros. This is
sub-optimal, but expected.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] Unsolicited download of remote resources

[Leo Butler]

On Fri, Feb 02 2024, Max Nikulin  wrote:

> Hi,
>
> Org git main HEAD, try to open the following file:
>
> --- 8< ---
>
> #+setupfile: http://localhost:8000/setup-1234567890.org
>
> test
> --- >8 ---
>
> I am trying to decline attempts to download the remote resource by 
> hitting "n" (skip), but Org still tries to fetch that file and does it 
> twice. I see in the *Messages*
>
> Please type y, n, d, or !: n
> Contacting host: localhost:8000
> Org couldn’t download "http://localhost:8000/setup-1234567890.org": 
> file-error ("make client process failed" "Connection refused" :name 
> "localhost" :buffer # :host "localhost" :service 8000 
> :nowait nil :tls-parameters nil :coding nil)
>
> Please type y, n, d, or !: n
> Contacting host: localhost:8000
> Org couldn’t download "http://localhost:8000/setup-1234567890.org": 
> file-error ("make client process failed" "Connection refused" :name 
> "localhost" :buffer # :host "localhost" :service 8000 
> :nowait nil :tls-parameters nil :coding nil)
>
>  From my point of view Org should not do it. Assume it is not a file I 
> created myself, but it is downloaded from some web server or received in 
> a e-mail message.

When I opened your email in Gnus, I was greeted with the same
(bewildering) message. Given that Org still tried to download the
setupfile after being told not to, I think this is a majour security
hole.

This is also related to another thread concerning Org and email.

https://list.orgmode.org/orgmode/87cyteyhif.fsf@localhost/

Leo

[BUG] Unsolicited download of remote resources

[Max Nikulin]

Hi,

Org git main HEAD, try to open the following file:

--- 8< ---
#+setupfile: http://localhost:8000/setup-1234567890.org

test
--- >8 ---

I am trying to decline attempts to download the remote resource by 
hitting "n" (skip), but Org still tries to fetch that file and does it 
twice. I see in the *Messages*


Please type y, n, d, or !: n
Contacting host: localhost:8000
Org couldn’t download "http://localhost:8000/setup-1234567890.org": 
file-error ("make client process failed" "Connection refused" :name 
"localhost" :buffer # :host "localhost" :service 8000 
:nowait nil :tls-parameters nil :coding nil)


Please type y, n, d, or !: n
Contacting host: localhost:8000
Org couldn’t download "http://localhost:8000/setup-1234567890.org": 
file-error ("make client process failed" "Connection refused" :name 
"localhost" :buffer # :host "localhost" :service 8000 
:nowait nil :tls-parameters nil :coding nil)


From my point of view Org should not do it. Assume it is not a file I 
created myself, but it is downloaded from some web server or received in 
a e-mail message.
#+setupfile: http://localhost:8000/setup-1234567890.org

test