bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#58774: 29.0.50; [WISH]: Let us make EWW browse WWW Org files correct


From: Jean Louis
Subject: bug#58774: 29.0.50; [WISH]: Let us make EWW browse WWW Org files correctly
Date: Thu, 27 Oct 2022 20:58:21 +0300
User-agent: Mutt/2.2.7+37 (a90f69b) (2022-09-02)

* Max Nikulin <manikulin@gmail.com> [2022-10-27 18:40]:
> On 27/10/2022 11:55, Jean Louis wrote:
> > 
> > Now is clear that main problem here is that Org advertises somewhere
> > to be "text" in MIME context, while it is not, it is by default
> > "application" and thus unsafe, see:
> ...
> > Text Media Types
> > https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.1
> 
> I do not see any problem or any difference what MIME type you are going to
> associate with Org mode. I agree with Arne that text/... type is more
> appropriate for a format readable as text. I do not see any contradictions
> with that RFC.

You were the one speaking and reporting that Org executes Emacs Lisp.

And now you imply that it is safe to open it because it is text? 👀

If Org or any file implies possible execution when loaded, and Org
implies it, it is not any more "text/*" MIME type.

From:
https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.5

> 4.2.5.  Application Media Types

>    The "application" top-level type is to be used for discrete data that
>    do not fit under any of the other type names, and particularly for
>    data to be processed by some type of application program.  This is
>    information that must be processed by an application before it is
>    viewable or usable by a user.

That is exactly the case with Org. Of course, one could minimize org
file to empty string, and say this is Org file and there is no
execution necessary, so it is "text".

Otherwise information must be processed by application which is
clearly the Org package before it is viewable or usable by a user.

> Expected uses for the "application" type name include but are not
> limited to file transfer, spreadsheets, presentations, scheduling
> data, and languages for "active" (computational) material.

✔️ YES, we have spreadsheets in Org which results may be viewable only
after computed.

✔️ YES, we have scheduling data, which is viewable only in Org agenda
or by using computations.

✔️ YES, we have languages for active computational material.

> (The last, in particular, can pose security problems that must be
> understood by implementors.  The "application/postscript" media type
> registration in [RFC2046] provides a good example of how to handle
> these issues.)

> For example, a meeting scheduler might define a standard
> representation for information about proposed meeting dates.

✔️ YES, we have that functionality in Org.

> An intelligent user agent would use this information to conduct a
> dialog with the user, and might then send additional material based
> on that dialog.

> More generally, there have been several "active" languages developed
> in which programs in a suitably specialized language are transported
> to a remote location and automatically run in the recipient's
> environment.  Such applications may be defined as subtypes of the
> "application" top-level type.

✔️ YES, that is exactly what we have in Org mode, as Babel allows
executions of several active languages, and by transferring Org files,
to remote location they may be automatically run in the recipient's
environment.

> The subtype of "application" will often either be the name or include
> part of the name of the application for which the data are intended.
> This does not mean, however, that any application program name may
> simply be used freely as a subtype of "application"; the subtype needs
> to be registered.

-- 
Jean

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

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]