Re: [BUG] Org may fetch remote content without asking user consent

[Ihor Radchenko]

Max Nikulin  writes:

> On 08/02/2024 22:07, Ihor Radchenko wrote:
>> 
>> `org--safe-remote-resource-p' checks the containing Org file as well, in
>> addition to #+included URL.
>
> If my reading of the code is correct then it considers 
> /ssh:host:org/include.org as safe if file:///ssh:host:org/test.org is 
> added to `org-safe-remote-resources'. I was considering a case when 
> there is no matching entry in `org-safe-remote-resources'. The user 
> opens (C-x C-f) /ssh:host:org/test.org and likely it is enough to 
> consider /ssh:host:org/include.org safe as well due to the same origin 
> "/ssh:host:".

I don't think so. And even if it is safe, I do not view it as a major
obstacle that will annoy users. There is an option to add the current
host to safe resources. No reason to layer complicated logic here -
simpler is more reliable.

>>> I am not confident in proper policy though. When some URI matches a
>>> pattern in the safe list, likely it is suitable for files created by the
>>> user and it is not really safe to allow it for a mail message attachment.
>> 
>> May you elaborate?
>
> Consider a user that has "#+include:" loaded from their own public 
> repository and used for some babel computations. It is safe when 
> included into user's files. I am not sure that it is safe for an org 
> file opened through a link in the browser. Perhaps it is better to avoid 
> included files in `org-safe-remote-resources' and add local directories 
> there.

What we may do is to add #+include + current file combination as safe
when user answers "!".

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

Re: [BUG] Org may fetch remote content without asking user consent

[Max Nikulin]

On 08/02/2024 22:07, Ihor Radchenko wrote:

Max Nikulin writes:

Max Nikulin writes:


Browsers
have concept of same origin for applying security and privacy measures.


Consider a file opened as /ssh:host:org/test.org that has

#+setupfile: /ssh:host:org/include.org

Formally it is a remote file, actually it resides on the same host as
the current document. Perhaps user consent is redundant.


`org--safe-remote-resource-p' checks the containing Org file as well, in
addition to #+included URL.


If my reading of the code is correct then it considers 
/ssh:host:org/include.org as safe if file:///ssh:host:org/test.org is 
added to `org-safe-remote-resources'. I was considering a case when 
there is no matching entry in `org-safe-remote-resources'. The user 
opens (C-x C-f) /ssh:host:org/test.org and likely it is enough to 
consider /ssh:host:org/include.org safe as well due to the same origin 
"/ssh:host:".



I am not confident in proper policy though. When some URI matches a
pattern in the safe list, likely it is suitable for files created by the
user and it is not really safe to allow it for a mail message attachment.


May you elaborate?


Consider a user that has "#+include:" loaded from their own public 
repository and used for some babel computations. It is safe when 
included into user's files. I am not sure that it is safe for an org 
file opened through a link in the browser. Perhaps it is better to avoid 
included files in `org-safe-remote-resources' and add local directories 
there.

Re: [BUG] Org may fetch remote content without asking user consent

[Ihor Radchenko]

Max Nikulin  writes:

> On 08/02/2024 00:10, Ihor Radchenko wrote:
>> Max Nikulin writes:
>> 
>>> It is a bit more tricky. Current file may be remote as well. Browsers
>>> have concept of same origin for applying security and privacy measures.
>>> Org needs something similar.
>> 
>> May you please elaborate?
>
> Consider a file opened as /ssh:host:org/test.org that has
>
> #+setupfile: /ssh:host:org/include.org
>
> Formally it is a remote file, actually it resides on the same host as 
> the current document. Perhaps user consent is redundant.

`org--safe-remote-resource-p' checks the containing Org file as well, in
addition to #+included URL.

> ...
> or the user has /ssh:host:org/ in the list of safe URIs. So there is no 
> need to treat such coincidence in a special way.

I think that it is indeed good enough.

> I am not confident in proper policy though. When some URI matches a 
> pattern in the safe list, likely it is suitable for files created by the 
> user and it is not really safe to allow it for a mail message attachment.

May you elaborate?

> Default protection should not be excessively strict, otherwise users 
> will disable it completely.

Agree.

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

Re: [BUG] Org may fetch remote content without asking user consent

[Max Nikulin]

On 08/02/2024 00:10, Ihor Radchenko wrote:

Max Nikulin writes:


It is a bit more tricky. Current file may be remote as well. Browsers
have concept of same origin for applying security and privacy measures.
Org needs something similar.


May you please elaborate?


Consider a file opened as /ssh:host:org/test.org that has

#+setupfile: /ssh:host:org/include.org

Formally it is a remote file, actually it resides on the same host as 
the current document. Perhaps user consent is redundant.


On the other hand, the file likely either contains

#+setupfile: include.org

or the user has /ssh:host:org/ in the list of safe URIs. So there is no 
need to treat such coincidence in a special way.


I am not confident in proper policy though. When some URI matches a 
pattern in the safe list, likely it is suitable for files created by the 
user and it is not really safe to allow it for a mail message attachment.


Default protection should not be excessively strict, otherwise users 
will disable it completely.

Re: [BUG] Org may fetch remote content without asking user consent

[Ihor Radchenko]

Max Nikulin  writes:

> On 07/02/2024 23:12, Ihor Radchenko wrote:
>> Max Nikulin writes:
>> 
>>> #+setupfile: /dav:localhost#8000:/msg-123456.org
> [...]
>> I think we can enable checking for anything where `file-remote-p'
>> returns non-nil.

> ... In addition, TRAMP locations should be 
> checked against `org-safe-remote-resources' as well.

This is what I propose. `file-remote-p' will return non-nil on TRAMP locations.

> It is a bit more tricky. Current file may be remote as well. Browsers 
> have concept of same origin for applying security and privacy measures. 
> Org needs something similar.

May you please elaborate?

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

Re: [BUG] Org may fetch remote content without asking user consent

[Max Nikulin]

On 07/02/2024 23:12, Ihor Radchenko wrote:

Max Nikulin writes:


#+setupfile: /dav:localhost#8000:/msg-123456.org

[...]

I think we can enable checking for anything where `file-remote-p'
returns non-nil.


It is a bit more tricky. Current file may be remote as well. Browsers 
have concept of same origin for applying security and privacy measures. 
Org needs something similar. In addition, TRAMP locations should be 
checked against `org-safe-remote-resources' as well.

Re: [BUG] Org may fetch remote content without asking user consent

[Ihor Radchenko]

Max Nikulin  writes:

> Consider the following .org file:
>
> --- 8< ---
> #+setupfile: /dav:localhost#8000:/msg-123456.org
> --- >8 ---
>
> When Emacs opens it, HTTP server (plain HTTP, not WebDAV is used for 
> test) logs contain
> ...
> Emacs *Messages* buffer:
>
> Tramp: Opening connection for localhost using dav...failed
> ...
> No dialog whether the file should be downloaded is displayed.
>
> My expectation is that Org should not connect to remote servers in 
> default configuration unless it is explicitly approved by the user.

We only protect from files matching `org-url-p'.
TRAMP files are not checked.

I think we can enable checking for anything where `file-remote-p'
returns non-nil.

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