Hello evrybody,

and since it is my first email after the release, A BIG THANK YOU to
those who made it possible !

Since Bullseye, the /etc/mime.types is provided in its own package, media-types, and in Bookworm I would like to brush up its contents
further.

/etc/mime.types is typically used by servers to provide a media type to
the receiver of a file, based on the extension of that file's name.
Thus, it is expected that file extensions appear only once in
/etc/mime.types.

At the moment, one of the exceptions to this rule are some script
extensions, in particular sh, csh and tcl, which are present under both
the text/ and the application/ types.

Judging from IANA's registered types for other script languages, it
looks like the application type is more relevant. Also, the
application/ types appear first in our /etc/media.types file, and if I
remember well this gives them precedence anyway. A quick random check
in the Internet shows that there is no consistency on how shell scripts
are served, but that the application type is used among others.

Before I remove text/x-sh and the like so that shell and tcl scripts
files are served as 'application' like others, I would like to hear if
some of you see a potential problem with that.

Have a nice Sunday!

Charles

--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Aug 29, 2021 at 5:17 AM Charles Plessy wrote:

Before I remove text/x-sh and the like so that shell and tcl scripts
files are served as 'application' like others, I would like to hear if
some of you see a potential problem with that.

Do the new MIME types cause different behavior in common browsers? ie downloading instead of displaying or vice-versa.

--
bye,
pabs

https://wiki.debian.org/PaulWise

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 29 Aug 2021 at 14:17:10 +0900, Charles Plessy wrote:

Judging from IANA's registered types for other script languages, it
looks like the application type is more relevant. Also, the
application/ types appear first in our /etc/media.types file, and if I remember well this gives them precedence anyway. A quick random check
in the Internet shows that there is no consistency on how shell scripts
are served, but that the application type is used among others.

The major difference is fallback behaviour. If a client (web browser or
email client or similar) receives a file with a text/* type for which it
has no special handler, in the absence of other context it is expected
to treat it like text/plain, and show the file to the user as text. If a
client receives a file with an unknown application/* type, it is expected
to treat it like application/octet-stream, assume that viewing the file as
text would be pointless because the user wouldn't necessarily understand
it anyway, and offer to save it or open it in an external program instead.

Using types outside text/ is definitely appropriate for very verbose text languages like SVG and "flat" OpenDocument, where it's *technically*
text, and *technically* you could edit it with a text editor, but in
practice that's rarely what anyone wants.

For scripting languages like sh and Python, I'm not sure: either way
could be appropriate. Which is more common: sharing scripts as source
code to read and edit, or sharing scripts as executables to download
and run as-is? If the former, text/ makes sense, if the latter,
application/.

If scripts and other source code are to be served as application/*, it
would be good to check that all our "programmer's editor"-style programs
have a MIME association set up for that type. In an extremely quick survey
of the .desktop files of editors I happen to have installed on my GNOME
laptop: gedit (a text editor) only registers itself to handle text/plain,
GNOME Builder (an IDE for programmers) handles both text/ and application/
for a wide variety of languages, and gvim (a text editor in hard mode :-) mostly only handles text/ types, except for application/x-shellscript
where it only has application/ and not text/ for whatever reason.

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Charles:

On Sun, Aug 29, 2021 at 02:17:10PM +0900, Charles Plessy wrote:

Before I remove text/x-sh and the like so that shell and tcl scripts
files are served as 'application' like others, I would like to hear if
some of you see a potential problem with that.

Someone might see a problem, but I don't. However, I have a question.

Since Bullseye, the /etc/mime.types is provided in its own package, media-types, and in Bookworm I would like to brush up its contents
further.

What is the relationship between /etc/mime.types
and /usr/share/mime/globs, please? When to use the one and when,
the other?

I ask because I have been using /usr/share/mime/globs for all
purposes, and have not been using /etc/mime.types at all.

(You probably know already but to inform other readers:
the /usr/share/mime/globs file is installed by the
shared-mime-info package.)


-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEM1APDU+pwMhnuF4GcGMmQy2FIrwFAmEsD8oACgkQcGMmQy2F Iryxdw//XyK763INrZsG2xfLOzWs5ysnyvvz1WVv+/aFYKkUCpyJrgI6AYgOpYvW THRGyEtsgEb9ymVAhL3dMmlCACAWl78a4N+ou3VvWc2YfgWBXP2/CL+h2+TdlBrG GcN9V0QBNz7VEsbtBAEZOevM6hb43B07SxdhJT7p+P9eVv0VoWLTqNKGDnd9FXiz jmDq3X8f/DkN65Ou1I1tUNOmpU09QSVb6K8PUxQloUOJsdQTjk6lY6fYpXA9PYoH XKlgx5PI8/tMg+x8CBbziRGNbdZl6FwykCaA2UjpfI5Qmhu5KQ8rdh83kEdeTZ0z EYsn9aXXmCO9B34giJ7nWQrbq9J5dBbDuY+UktTzFnPnEngbHshxvcCwDkhj9S0+ FJrVDWiQk38BoybDQZukr6/020tRZ45aT5XDUAmG4d9wVQnDYDsjN4A5Wske+e75 mfwX5QEVDSi0Vbccg5Wevo/o0nqol/yQyarOzglHibYtgkqu85EprE2F6iMdLOhG A8loidaAEIKINkTEMbYBTr1TNxq6UOWEuRDDioaqGGNAfd+Tey/6FZ+J8D6EMWgW N6oKo2fkGKt1omxRJOigt7H+KWbdmb3yJUmPHAJ2i3xo7gH1v+CpMjjauflEaleF Ofsy6CKBTC8wbSERB2MpzwYhwDhloU9KlS1nDaKzaibSCMYILPk=
=PH1o
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Aug 29, 2021 at 2:13 PM Simon McVittie wrote:

For scripting languages like sh and Python, I'm not sure: either way
could be appropriate. Which is more common: sharing scripts as source
code to read and edit, or sharing scripts as executables to download
and run as-is? If the former, text/ makes sense, if the latter,
application/.

I would lean towards encouraging review of scripts rather than
downloading and executing them.

If scripts and other source code are to be served as application/*, it
would be good to check that all our "programmer's editor"-style programs
have a MIME association set up for that type. In an extremely quick survey
of the .desktop files of editors I happen to have installed on my GNOME laptop: gedit (a text editor) only registers itself to handle text/plain, GNOME Builder (an IDE for programmers) handles both text/ and application/ for a wide variety of languages, and gvim (a text editor in hard mode :-) mostly only handles text/ types, except for application/x-shellscript
where it only has application/ and not text/ for whatever reason.

application/x-shellscript seems to have wider support than text/x-shellscript:

https://wiki.debian.org/MimeTypesSupport/PackageList

--
bye,
pabs

https://wiki.debian.org/PaulWise

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le Sun, Aug 29, 2021 at 10:53:04PM +0000, Thaddeus H. Black a écrit :

What is the relationship between /etc/mime.types
and /usr/share/mime/globs, please? When to use the one and when,
the other?

Hi Thaddeus,

/etc/mime.types is a conffile; you can edit it and dpkg will ensure to
preserve the changes or prompt you in case of conflicts during upgrades.

/usr/share/mime/globs is an autogenerated file. Any change you make
there can be silently lost.

Also, /etc/mime.types is provided by a package, media-types, that
contains only this file, does not have dependancies and is more likely
to be installed on desktopless systems.

So if you only need a one-to-one lookup table for associating media
types and file extensions, and if you need to allow easy extension and customisation by the local administrator, you should better use /etc/mime.types.

The information in both files overlap a lot since most of it has the same origin: the media types registered at the IANA.

https://www.iana.org/assignments/media-types/media-types.xhtml

This said, the XDG's shared MIME-info database contains much more
information than /etc/mime.types, such as magic numbers or subtypes.
If you write an application for a system where you can be sure that
this information is available, use it !

Cheers,

Charles

--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Simon McVittie dijo [Sun, Aug 29, 2021 at 03:13:02PM +0100]:

Using types outside text/ is definitely appropriate for very verbose text languages like SVG and "flat" OpenDocument, where it's *technically*
text, and *technically* you could edit it with a text editor, but in
practice that's rarely what anyone wants.

For scripting languages like sh and Python, I'm not sure: either way
could be appropriate. Which is more common: sharing scripts as source
code to read and edit, or sharing scripts as executables to download
and run as-is? If the former, text/ makes sense, if the latter,
application/.

I side with Paul Wise -- If a script is served by a Web server to a
browser, I don't think the desired result will be to download and
execute right away. text/* seems much better suited for me. Users
willing to execute said scripts should download and execute locally --
and nobody should be bitten by the surprise of automatic (even after
a UI acknowledgement) code execution of random Internet content.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Quoting Paul Wise (2021-08-30 02:32:14)

On Sun, Aug 29, 2021 at 2:13 PM Simon McVittie wrote:

For scripting languages like sh and Python, I'm not sure: either way
could be appropriate. Which is more common: sharing scripts as source
code to read and edit, or sharing scripts as executables to download
and run as-is? If the former, text/ makes sense, if the latter, application/.

I would lean towards encouraging review of scripts rather than
downloading and executing them.

I would lean towards encouraging review of **all** objects downloaded
online - not only scripts.

My point is, that I think the reasoning above is wrong: Improving user-operated web agents a.k.a. web browsers is better done at another
layer than the classification of objects.

Is readability or executability the primary feature of a script?

I'd say it is the executability feature.

Yes, executing stuff can be dangerous sometimes, but emphasizing other features is a bad security practice. If you sell a gun then warn that
it can damage feet - don't emphasize how it can be used as a hammer.


- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private --==============s65278652090520750=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmEs+2sACgkQLHwxRsGg ASFz1g/8C2uCEmqGfV6k4kU3YQmn9u4Qq/WxES2fBPcyddxXVymlc0phr6DX86pk 7vNIWGO47lG6Wx2ep1N/utoWrkODR5EiDbzdOHZAy5N29r6yNGXb3k8g3zdHohWw +7cl8QnNfsDuFUIZWMaU8ZmRNBv2KFJlLNaMcpub66P43qqY++doMrFpV0Q1sOua QmH/vBOYLD7rlTsrXvzdfgON8coXIQxaf5yg5URRRUapBKrN1dqe9NQpwMnuR+Xr Le2n8tyMMiBVk5hykx2YoOPTHWPQ8iQsPfjsyv66bQ44P4PVUNZjQ6Wwwb5JpwqS xxJKt6tyzySpXKiNNvgc+uG2pHLp+3JgiJb5g36DTu7KJOLy9Ksn0NZcTA4XRIKf OO6fDkTaG4petENvegqx5lxSgvedsldvTNW1mzDx+ZN3XhofLtYm1VxQ8/5sS54o EslW/WcW0Bu++1lCOHNhOAzwurG8td7WcRIVfu9rhbH+BE0M5wyrhikPdaxD5+uz QNxFbsvo8gTCVkUCr

Gunnar Wolf <gwolf@debian.org> writes:

Simon McVittie dijo [Sun, Aug 29, 2021 at 03:13:02PM +0100]:

Using types outside text/ is definitely appropriate for very verbose
text languages like SVG and "flat" OpenDocument, where it's
*technically* text, and *technically* you could edit it with a text
editor, but in practice that's rarely what anyone wants.

For scripting languages like sh and Python, I'm not sure: either way
could be appropriate. Which is more common: sharing scripts as source
code to read and edit, or sharing scripts as executables to download
and run as-is? If the former, text/ makes sense, if the latter,
application/.

I side with Paul Wise -- If a script is served by a Web server to a
browser, I don't think the desired result will be to download and
execute right away.

I certainly hope that no web browser would download *and execute* a script
from the web without user intervention. I think the primary difference
between application/* and text/* is whether the web browser will display
the script like a web page by default or whether it will download it (but
not execute it) by default.

I'm not sure either of those will always be right. In some cases, the
download behavior is probably desirable and displaying the script as text
will be irritating and make it harder to save; in other cases, downloading
it first will be annoying. I personally would probably prefer the text/* behavior most of the time, but I'm also not a typical user.

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Quoting Gunnar Wolf (2021-08-30 17:07:23)

Simon McVittie dijo [Sun, Aug 29, 2021 at 03:13:02PM +0100]:

Using types outside text/ is definitely appropriate for very verbose text languages like SVG and "flat" OpenDocument, where it's *technically*
text, and *technically* you could edit it with a text editor, but in practice that's rarely what anyone wants.

For scripting languages like sh and Python, I'm not sure: either way
could be appropriate. Which is more common: sharing scripts as source
code to read and edit, or sharing scripts as executables to download
and run as-is? If the former, text/ makes sense, if the latter, application/.

I side with Paul Wise -- If a script is served by a Web server to a
browser, I don't think the desired result will be to download and
execute right away. text/* seems much better suited for me. Users
willing to execute said scripts should download and execute locally --
and nobody should be bitten by the surprise of automatic (even after a
UI acknowledgement) code execution of random Internet content.

You cannot know that a human is at the other end of the exchange.

You can choose to be honest about what your serve your audience, or you
can try steer them when you think that you know better than them what
they should do with it.

I think that the game of steering certain types of users belongs in the configuration files of web servers for specific web sites, not in the
general defaults of the whole system.


- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private --==============v36945270249702405=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmEs/qYACgkQLHwxRsGg ASHCZA/+PxjMyd3r6w+jvRHyKsgi3b1GA5EsfUHulcxE5XOvz70P4YhqflGcg+Uy yn/m0VZdtn5nDBv9vMOWVhQdziwu4NNKqAiURizzlXp8WoeCMBzzHCr1q/9wcOOs 118cnJ3MI0DaM2qK84lLI+cykXI1RV6vIoIxaps6uaRtNNHx8k9EMBxo+rbBdjgz t5f0HwCznvqjsN+8YRZEV+sgd4FbzUuyt07gg+fArWQSaWioXgItCDWRELpUEOTo TPCFIElRO63bAmiw5MmtY79wDgq2dSptQTbiYgWAR6e3UVGYTjeRFmlh3Bvin/u5 sE6nKQEJUgsskZuYBc3BzNArPP4dK+s6oTNR79T/LK+re7zfsdc2Onzq5YwB5C2v YFUahZka9BvSsudpwOjhs51kfIj1qc8l4DZWDq2ODoNfIDEdpU77me3+XI7KKACe fGeqrpp1R/RZ/fuuRtwq3YUyGqP2XJQqhqhAp7CcAybhXJGSmDAw+uS4YSD92lQe mdtriK2P1KHl1v5l/

On 2021-08-30 22:58:45 +0100 (+0100), Roger Lynn wrote:
[...]

It is usually easy to save a text file from a web browser, while
it is hard (impossible?) to persuade it to display an unknown
application/* type. Thus, even if your latter example is more
common, it may be preferable use text/.

I too prefer to view them as text, but this seems like something
which should be fixed *in* the browsers/clients, not worked around
at the server side (and more importantly, not by baking those
workarounds into default configuration). If everyone just serves the workaround, the client-side bugs will almost certainly never be
fixed.
--
Jeremy Stanley

-----BEGIN PGP SIGNATURE-----

iQKTBAABCgB9FiEEl65Jb8At7J/DU7LnSPmWEUNJWCkFAmEtXz9fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 QUU0OTZGQzAyREVDOUZDMzUzQjJFNzQ4Rjk5NjExNDM0OTU4MjkACgkQSPmWEUNJ WCkINBAAoqgfP1AM9YRBJomJJEwcaN1f75x8v4sLSJuJ8c9SHShHWu4T/5dV0jpu SKSEcbMzJoU7A92yHa4NRcpG8mMgt5W9U+d3OvY8hSjWd//oaICsZMVQIv8xVhEs No9vUQA9rapCsnsMKQOp2QBTJuAs+zqzI1oB8RNkWJLNm2GrIDuNoHMNCrv8Ne7q 5YmZLkX2ggpaRUWvMguDBxLJwahMG0oCj4wvtAw0U1Fsh5UrkIhoCQo8RC66DMon JvZ/VnnhBUW8MpKIbcSFHu7fUOVpAB0nh8qxkpvtTra7qn0eJINDyocGhN0oLhpK Ffy69TAWXejqdN3TgH9LYZ3Vy25lRy+LqKI58kTjzvu9JAmjpmF4yvtaliIIaUzr sEjouqMFaMcKwsa6q13AFrQW0057SuOXUQd11pccqay2RBEnd8/ard84PwjzQdj7 ftT/2lq6JPg6sm/VfG67TGW5Nhgz0LCSvDqWUdaAF9uCTEolUmdh2PSrrccNoIU/ Yo+DCGLXKFwzSDGx3ndiW9FBGpG9/WAwaXbMXgPBOqqBYkq/lgE1I2xPk1e63GFu zc8wpBUVp7E585jIOr7mSPXNVmS5OVPkhid4TaLq8gaZu0nzgnCdL/IvOooaEi3/ +VWfYLM+ZRsUH/jHlYIOJHPHdxVvWZnqdaw5HYqktjM6+WlOzMM=
=66OG
-----END PGP SIGNATURE-----

--- SoupGate-Win32

On 29/08/2021 15:20, Simon McVittie wrote:

The major difference is fallback behaviour. If a client (web browser or
email client or similar) receives a file with a text/* type for which it
has no special handler, in the absence of other context it is expected
to treat it like text/plain, and show the file to the user as text. If a client receives a file with an unknown application/* type, it is expected
to treat it like application/octet-stream, assume that viewing the file as text would be pointless because the user wouldn't necessarily understand
it anyway, and offer to save it or open it in an external program instead.

[snip]

For scripting languages like sh and Python, I'm not sure: either way
could be appropriate. Which is more common: sharing scripts as source
code to read and edit, or sharing scripts as executables to download
and run as-is? If the former, text/ makes sense, if the latter,
application/.

It is usually easy to save a text file from a web browser, while it is hard (impossible?) to persuade it to display an unknown application/* type. Thus, even if your latter example is more common, it may be preferable use text/.

Roger

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Aug 30, 2021 at 10:58:45PM +0100, Roger Lynn wrote:

It is usually easy to save a text file from a web browser, while it is hard (impossible?) to persuade it to display an unknown application/* type. Thus, even if your latter example is more common, it may be preferable use text/.

There's a Firefox addon that you can use to tell the browser to just
try displaying whatever it is as text (or image or a few other options)
rather than spawning an application or saving it:

https://addons.mozilla.org/en-US/firefox/addon/open-in-browser/

This plugin has vastly improved my opinion of Firefox.

Thanks

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEQVAQ8bojyMcg37H18yFyWZ2NLpcFAmEtaH0ACgkQ8yFyWZ2N Lpe3bAf6A+9ObLnis5JJ72DDQs8zTAgsrxkeO92ziTsK3gJXPqzCvsDjzdhhvfbG dJ5FZq9HGrzQxz+8iA0rbxj+j+Ivtz4m5U3eoFDogcriwryaMsR9yNiCs4WfYtIF v5q0FsWyDVgyRtCP1SQtTsbHMzieIr9gM8t3Mv6LlFLMBOyMB+SevDuAiIqxLSi7 abZbZyl5l7QS01GTYTIwJIXhZemknvRVyWdR92JysvLg/thuWyp6U+JyRRj8PFGZ h+zvEVsn+S9/12d2kt0JKappjEByRXgHo4yEU23rMfmJ21AYKpf1JXaXTrqqf7NY 18h5gIwOTflDE37O1+2r9JTfbCbVdg==
=OwS3
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)