unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Jean Louis <bugs@gnu.support>
To: Max Nikulin <manikulin@gmail.com>
Cc: 58774@debbugs.gnu.org, Org Mode List <emacs-orgmode@gnu.org>
Subject: bug#58774: 29.0.50; [WISH]: Let us make EWW browse WWW Org files correctly
Date: Thu, 27 Oct 2022 21:25:49 +0300	[thread overview]
Message-ID: <Y1rNLMLcYI+ImsGU@protected.localdomain> (raw)
In-Reply-To: <d8bead8c-f97d-1de5-ae06-df81fefb7389@gmail.com>

* Max Nikulin <manikulin@gmail.com> [2022-10-27 18:41]:
> Chromium is able to display text/x-org internally just as text/plain and I
> like it as a way to preview and review file contents.

Org file is for Emacs. It is not for Chromium.

Just as you can display application/json in Chromium as text, does not
make application/json less "application/*" MIME type.

Displaying Org in Chromium is useless, as I cannot use Org features,
Chromium is not for that, and it's not suitable example.

Suitable example is that Chromium may be configured to open Org file
correctly with Emacs and as you have mentioned, there will be executions.

> I have not managed to configure Firefox to achieve the same behavior
> that allows to avoid an external application (certainly not Emacs at
> first).

I wonder on which mailing list I am.

Of course I want Org file be opened by Emacs. I am user of Org
files and Emacs. I am not vim user (unless Emacs flunks).

> > We can't just speak of safety alone when we are in general
> > computing environment, we must also speak of usefulness.
> 
> I do not mind to have org-view-mode that saves me from execution some code
> unintentionally. Since most of the code was written without having in mind
> such feature, I expect a lot of iterations before all possibilities to run
> code will be plumbed. I suspect that it is possible to ruin whole protection
> by a small piece of elisp code. I am unaware of sandboxing in Emacs. I
> expect that making Org mode safe enough will require a lot of efforts by
> developers.

Exactly.

> Your are pushing Org to rather hostile environment: highly automated
> attacks to distribute exploits, market of breached computers
> listening for remote commands.

Tittle-tattle. 😵‍💫 But America has been already discovered.

Remember, any type of application, software, is already for billions
of times delivered by Internet and executed on user's devices.

Flatpak, APK, EXE files, Java, shell files, hoooooo, too long
list. And where we are now? In Emacs world, where packages are
distributed from all kinds of sources and executed on users's
computers. 

"Pushing Org" to rather hostile environment is exaggeration.

> A running cryptominer would be rather innocent consequence, through
> the same backdoor you may receive an encryptor or various stuff
> searching for credentials and access tokens in your files.

Of course I understand that.

Do you wish to say that users should not have the freedom to customize
web browser to click on Org file and open it with Emacs?

Are we not on Emacs related mailing list?

If I am pushing Org into hostile environment, than you are implying
that we as Org users are hostile environemnt. Are we really?

> Emacs is protected mostly by its low popularity. A lot of efforts
> have been invested in browser making attacks more expensive, but
> still attractive due to possible benefits. I do not like to increase
> surface for attacks. Someone may create a plugin targeting Emacs
> users just because it would be easy enough.

And? 

> Consider converting Org files to HTML as an unpleasant tax for the
> sake of safety.

Personally, definitely not. Such files do not give me freedom to work
with my Org data. It is way of presenting things, not handling it.

> > All I want is to access my personal read-only Org files by using WWW
> > and browse from one to the other by using links.
> 
> How are you going to distinguish your personal files and arbitrary files
> from non-trusted sources? By signing your files and maintaining list of
> trusted certificates?

🤣 Am I Joe Biden or other gaga that I do not know what are my files? 

> For personal notes I would expect e.g. private instance of nextcloud
> file share (that is internally HTTP server), not accessing files
> directly through HTTP.

HTTP is transfer protocol, not my mamma to tell me what I am going to
transfer in my room.

Nextcloud is application that runs on computer and is served by web
server. It allows file share to public as well. 

I understand your point of protecting private files on web
server. That shall be natural to every person hosting such
files. Nextcloud is bloated way to do such hosting.

Simplest way to protect files is to upload files and use web server
authentication.

And web server does not mean that files are distributed on public
WWW. We use here ethernet, and we share files from device to device by
using HTTP server. You can't access those files, they are beyond
public IP address space.

I need help to make it work right, can you help?

I load this:

(defvar eww-content-type nil)
(put 'eww-content-type 'permanent-local t)

then I put this below in `eww-render' after (let

;;; (setq eww-content-type content-type)

Then I use this:

(defun rcd-eww-content-type ()
  (cond ((string-match-p "text/x-org" (car eww-content-type)) (org-mode))
	 (t WHAT-HERE?)))

(add-hook 'eww-after-render-hook 'rcd-eww-content-type)

But I am doing it wrong, that will correctly invoke org mode, but then
it does not return back to normal EWW work. I have tried to remember
the major mode and invoke it again. But it is not that it works.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/





  parent reply	other threads:[~2022-10-27 18:25 UTC|newest]

Thread overview: 49+ 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 21:54     ` Dr. Arne Babenhauserheide
2022-10-26  7:57       ` bug#58774: " Jean Louis
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 13:19               ` Jean Louis
     [not found]               ` <Y1kz5PKQh1SMr1BO@protected.localdomain>
2022-10-26 13:55                 ` Andreas Schwab
     [not found]                 ` <mvmh6zqadu9.fsf@suse.de>
2022-10-26 17:36                   ` Jean Louis
     [not found]                   ` <Y1lwNABImLQnQojU@protected.localdomain>
2022-10-27  7:58                     ` Andreas Schwab
     [not found]                     ` <mvma65hae9p.fsf@suse.de>
2022-10-27  8:40                       ` Jean Louis
     [not found]                       ` <Y1pD/h1INh3457ou@protected.localdomain>
2022-10-27 11:22                         ` Andreas Schwab
2022-10-27 11:23                         ` Dr. Arne Babenhauserheide
2022-10-26  7:59       ` Jean Louis
2022-10-25 23:03   ` Ihor Radchenko
2022-10-26  6:07     ` bug#58774: " Stefan Kangas
     [not found]     ` <CADwFkm=zOc6K6=eOa_WgXrnnpCRa47wKHeB+yfDM4Q0Fjzjd8A@mail.gmail.com>
2022-10-26  6:52       ` Ihor Radchenko
2022-10-26  8:21       ` Jean Louis
2022-10-26 17:07         ` Max Nikulin
2022-10-26 18:37           ` Jean Louis
2022-10-26 21:16             ` Dr. Arne Babenhauserheide
2022-10-26 21:56             ` indieterminacy
     [not found]       ` <87zgdjoz3r.fsf@localhost>
2022-10-26  8:24         ` Jean Louis
2022-10-26 20:22           ` indieterminacy
2022-10-26 11:30         ` Dr. Arne Babenhauserheide
2022-10-26 13:15         ` Stefan Kangas
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-27  4:55 ` Jean Louis
2022-10-27 11:13   ` Dr. Arne Babenhauserheide
2022-10-27 17:41     ` Jean Louis
2022-10-27 21:43       ` Dr. Arne Babenhauserheide
2022-10-27 15:35   ` Max Nikulin
     [not found]   ` <d8bead8c-f97d-1de5-ae06-df81fefb7389@gmail.com>
2022-10-27 17:58     ` Jean Louis
2022-10-27 21:49       ` Dr. Arne Babenhauserheide
2022-10-27 18:25     ` Jean Louis [this message]
2022-10-27 19:53       ` Quiliro Ordóñez
2022-10-27 19:58       ` Quiliro Ordóñez
2022-10-27 21:57     ` Dr. Arne Babenhauserheide
     [not found]     ` <87y1t0or6q.fsf@web.de>
2022-10-27 22:18       ` Jean Louis
     [not found]       ` <Y1sD0bXYnDCY2Yw4@protected.localdomain>
2022-10-27 23:14         ` Dr. Arne Babenhauserheide
2022-10-27 23:20       ` Ihor Radchenko
     [not found]       ` <87zgdgn9av.fsf@localhost>
2022-10-28  8:28         ` Dr. Arne Babenhauserheide
     [not found]         ` <87h6zony3p.fsf@web.de>
2022-11-02  4:09           ` 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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y1rNLMLcYI+ImsGU@protected.localdomain \
    --to=bugs@gnu.support \
    --cc=58774@debbugs.gnu.org \
    --cc=emacs-orgmode@gnu.org \
    --cc=manikulin@gmail.com \
    /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
Be 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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.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).