From: Stefan Kangas <stefankangas@gmail.com> To: Ihor Radchenko <yantar92@posteo.net> Cc: 58774@debbugs.gnu.org, "Dr. Arne Babenhauserheide" <arne_bab@web.de>, emacs-orgmode@gnu.org, bugs@gnu.support Subject: bug#58774: 29.0.50; [WISH]: Let us make EWW browse WWW Org files correctly Date: Wed, 26 Oct 2022 06:15:22 -0700 [thread overview] Message-ID: <CADwFkmkS+8v4W5tqiGn29ixJxr+Udwg0GjdmN9onGkPoL7ePtg@mail.gmail.com> (raw) In-Reply-To: <87zgdjoz3r.fsf@localhost> Ihor Radchenko <yantar92@posteo.net> writes: >> Note that with the suggested feature, any link you follow risks being >> loaded in Org mode, before the user even has a chance to inspect the >> file. Which Org features, currently existing or introduced in the >> future, would EWW have to add workarounds for? > > That's not the case. Org never loads arbitrary code on loading the file > without querying the user. We seem to be miscommunicating. In the above, I was merely referring to whether org-mode is run when visiting some URL or not, which AFAIU is a binary thing (it either does, or it doesn't). You seem to be talking about security features in org-mode itself, which is related, but not the same thing. I agree that there are various security features in org-mode. I still don't think that we should run org-mode just because some URL requests it. To reiterate what I said, security problems are hard to audit and discover. We shouldn't expose users to additional risks just to add such a minor convenience feature. It is not a good trade-off. > Strictly speaking, even eww-mode may run arbitrary code given that user > puts something into eww-mode-hook. My concern is not that the users should run their own code, but that they will inadvertently run (potentially malicious) code provided by others. > I'd say that it will be safer to take care about necessary precautions > rather than leaving the user with the only option to run org-mode > manually. Adding a `safe-org-mode' would be an improvement, but orthogonal to whether or not we should automatically load org-mode when visiting any URL that presents itself as serving an org file. I think we should not do the latter. > If necessary, we can introduce a special variable in Org mode that will > disable all the potential third-party code evaluation, even if user has > customized Org to execute code without prompt. That would also be an improvement, yes. It would be even better if such a variable supported whitelisting, so that users could mark only specific files as safe for these purposes.
WARNING: multiple messages have this Message-ID (diff)
From: Stefan Kangas <stefankangas@gmail.com> To: Ihor Radchenko <yantar92@posteo.net> Cc: "Dr. Arne Babenhauserheide" <arne_bab@web.de>, 58774@debbugs.gnu.org, emacs-orgmode@gnu.org, bugs@gnu.support Subject: Re: bug#58774: 29.0.50; [WISH]: Let us make EWW browse WWW Org files correctly Date: Wed, 26 Oct 2022 06:15:22 -0700 [thread overview] Message-ID: <CADwFkmkS+8v4W5tqiGn29ixJxr+Udwg0GjdmN9onGkPoL7ePtg@mail.gmail.com> (raw) In-Reply-To: <87zgdjoz3r.fsf@localhost> Ihor Radchenko <yantar92@posteo.net> writes: >> Note that with the suggested feature, any link you follow risks being >> loaded in Org mode, before the user even has a chance to inspect the >> file. Which Org features, currently existing or introduced in the >> future, would EWW have to add workarounds for? > > That's not the case. Org never loads arbitrary code on loading the file > without querying the user. We seem to be miscommunicating. In the above, I was merely referring to whether org-mode is run when visiting some URL or not, which AFAIU is a binary thing (it either does, or it doesn't). You seem to be talking about security features in org-mode itself, which is related, but not the same thing. I agree that there are various security features in org-mode. I still don't think that we should run org-mode just because some URL requests it. To reiterate what I said, security problems are hard to audit and discover. We shouldn't expose users to additional risks just to add such a minor convenience feature. It is not a good trade-off. > Strictly speaking, even eww-mode may run arbitrary code given that user > puts something into eww-mode-hook. My concern is not that the users should run their own code, but that they will inadvertently run (potentially malicious) code provided by others. > I'd say that it will be safer to take care about necessary precautions > rather than leaving the user with the only option to run org-mode > manually. Adding a `safe-org-mode' would be an improvement, but orthogonal to whether or not we should automatically load org-mode when visiting any URL that presents itself as serving an org file. I think we should not do the latter. > If necessary, we can introduce a special variable in Org mode that will > disable all the potential third-party code evaluation, even if user has > customized Org to execute code without prompt. That would also be an improvement, yes. It would be even better if such a variable supported whitelisting, so that users could mark only specific files as safe for these purposes.
next prev parent reply other threads:[~2022-10-26 13:15 UTC|newest] Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-10-25 12:06 29.0.50; [WISH]: Let us make EWW browse WWW Org files correctly Jean Louis 2022-10-25 15:02 ` Dr. Arne Babenhauserheide 2022-10-25 19:56 ` bug#58774: " Jean Louis 2022-10-25 19:56 ` Jean Louis 2022-10-25 21:54 ` Dr. Arne Babenhauserheide 2022-10-26 7:57 ` bug#58774: " Jean Louis 2022-10-26 7:57 ` Jean Louis 2022-10-26 11:55 ` bug#58774: " Dr. Arne Babenhauserheide 2022-10-26 11:55 ` Dr. Arne Babenhauserheide 2022-10-26 12:20 ` Jean Louis 2022-10-26 12:45 ` bug#58774: " Andreas Schwab 2022-10-26 12:45 ` Andreas Schwab 2022-10-26 13:19 ` bug#58774: " Jean Louis 2022-10-26 13:55 ` Andreas Schwab 2022-10-26 17:36 ` Jean Louis 2022-10-27 7:58 ` Andreas Schwab 2022-10-27 7:58 ` Andreas Schwab 2022-10-27 8:40 ` Jean Louis 2022-10-27 8:40 ` Jean Louis 2022-10-27 11:22 ` Andreas Schwab 2022-10-27 11:22 ` Andreas Schwab 2022-10-27 11:23 ` Dr. Arne Babenhauserheide 2022-10-27 11:23 ` Dr. Arne Babenhauserheide 2022-10-26 17:36 ` Jean Louis 2022-10-26 13:55 ` Andreas Schwab 2022-10-26 13:19 ` Jean Louis 2022-10-26 7:59 ` Jean Louis 2022-10-26 7:59 ` Jean Louis 2022-10-25 23:03 ` Ihor Radchenko 2022-10-26 6:07 ` bug#58774: " Stefan Kangas 2022-10-26 6:07 ` Stefan Kangas 2022-10-26 6:52 ` Ihor Radchenko 2022-10-26 8:24 ` Jean Louis 2022-10-26 8:24 ` Jean Louis 2022-10-26 20:22 ` indieterminacy 2022-10-26 20:22 ` indieterminacy 2022-10-26 11:30 ` Dr. Arne Babenhauserheide 2022-10-26 21:41 ` Tim Cross 2022-10-27 10:43 ` Dr. Arne Babenhauserheide 2022-10-26 11:30 ` Dr. Arne Babenhauserheide 2022-10-26 13:15 ` Stefan Kangas [this message] 2022-10-26 13:15 ` Stefan Kangas 2022-10-26 6:52 ` Ihor Radchenko 2022-10-26 8:21 ` Jean Louis 2022-10-26 8:21 ` Jean Louis 2022-10-26 17:07 ` Max Nikulin 2022-10-26 17:07 ` Max Nikulin 2022-10-26 18:37 ` Jean Louis 2022-10-26 18:37 ` Jean Louis 2022-10-26 21:16 ` Dr. Arne Babenhauserheide 2022-10-26 21:16 ` Dr. Arne Babenhauserheide 2022-10-27 4:25 ` tomas 2022-10-27 11:10 ` Dr. Arne Babenhauserheide 2022-10-26 21:56 ` indieterminacy 2022-10-26 21:56 ` indieterminacy 2022-10-26 20:00 ` Tim Cross 2022-10-25 22:13 ` Ag Ibragimov 2022-10-26 8:28 ` Jean Louis 2022-10-26 13:00 ` Rudolf Adamkovič 2022-10-26 13:42 ` bug#58774: " Jean Louis 2022-10-26 13:42 ` Jean Louis 2022-10-27 4:55 ` Jean Louis 2022-10-27 4:55 ` Jean Louis 2022-10-27 11:13 ` bug#58774: " Dr. Arne Babenhauserheide 2022-10-27 11:13 ` Dr. Arne Babenhauserheide 2022-10-27 17:41 ` bug#58774: " Jean Louis 2022-10-27 17:41 ` Jean Louis 2022-10-27 21:43 ` bug#58774: " Dr. Arne Babenhauserheide 2022-10-27 21:43 ` Dr. Arne Babenhauserheide 2022-10-27 15:35 ` bug#58774: " Max Nikulin 2022-10-27 15:35 ` Max Nikulin 2022-10-27 17:58 ` Jean Louis 2022-10-27 17:58 ` Jean Louis 2022-10-27 21:49 ` Dr. Arne Babenhauserheide 2022-10-27 21:49 ` Dr. Arne Babenhauserheide 2022-10-27 18:25 ` Jean Louis 2022-10-27 18:25 ` Jean Louis 2022-10-27 19:53 ` Quiliro Ordóñez 2022-10-27 19:53 ` Quiliro Ordóñez 2022-10-27 19:58 ` Quiliro Ordóñez 2022-10-27 19:58 ` Quiliro Ordóñez 2022-10-27 21:57 ` Dr. Arne Babenhauserheide 2022-10-27 21:57 ` Dr. Arne Babenhauserheide 2022-10-27 22:18 ` Jean Louis 2022-10-27 23:14 ` Dr. Arne Babenhauserheide 2022-10-27 23:14 ` Dr. Arne Babenhauserheide 2022-10-27 22:18 ` Jean Louis 2022-10-27 23:20 ` Ihor Radchenko 2022-10-28 8:28 ` Dr. Arne Babenhauserheide 2022-10-28 8:28 ` Dr. Arne Babenhauserheide 2022-11-02 4:09 ` Ihor Radchenko 2022-11-02 4:09 ` Ihor Radchenko 2022-10-27 23:20 ` Ihor Radchenko 2023-09-02 8:53 ` Stefan Kangas
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 * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CADwFkmkS+8v4W5tqiGn29ixJxr+Udwg0GjdmN9onGkPoL7ePtg@mail.gmail.com \ --to=stefankangas@gmail.com \ --cc=58774@debbugs.gnu.org \ --cc=arne_bab@web.de \ --cc=bugs@gnu.support \ --cc=emacs-orgmode@gnu.org \ --cc=yantar92@posteo.net \ /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: linkBe 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 external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.