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

Bug#950319: libreoffice: filename replacements in mime entries for mailcap must not be quoted within the given command



Hi, thanks for such a quick reply.

On Thu, 17 Dec 2020 08:34:44 +0100, Rene Engelhard wrote:
> > 1) There is a Lintian test for this specific problem:
>
> I know and saw that one, and as long as there isn't a *definitive*
> answer am continuing what I am doing already: ignoring it.
>
> Or is lintians tag is a distro-wide decision? I don't take that for a
> given since they introduce bogus tags all the time .oO ( "breakout-link" )

I'm not familiar with Lintian and package management. I find it intuitive that maintainers should be able to ignore warnings if they know better, but in this case it would mean that the tag itself is pointless.

Grave bug #930908 was closed recently because "a Lintian test already exists", which also makes little sense if it doesn't represent distro policy.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930908#48

As an experiment, I've run /usr/sbin/update-mime on every one of the 57780 buster amd64 binary packages and collected the results.

I got a total of 6061 rules [1]:
- 5499 have only unquoted %-escapes [2]
-  510 have only quoted %-escapes [3]
-    7 have both [4]
-   45 have none

Packages producing rules are 762 [5]:
- 673 produce only unquoted %-escapes [6]
-  66 produce only quoted %-escapes [7]
-  19 produce both [8]
-   4 produce none

(Rules are prefixed by the package name; /etc/mailcap order is preserved.)
[1] https://pastebin.ubuntu.com/p/SVzHVBFFSt/
[2] https://pastebin.ubuntu.com/p/zqykzFMT9M/
[3] https://pastebin.ubuntu.com/p/rYxCZXstXs/
[4] https://pastebin.ubuntu.com/p/TvbcKnyGzM/

[5] https://pastebin.ubuntu.com/p/KPjPgZw7zp/
[6] https://pastebin.ubuntu.com/p/Vkwpb4rnCm/
[7] https://pastebin.ubuntu.com/p/6xkztMcYgN/
[8] https://pastebin.ubuntu.com/p/pdtS5FJTSt/

I understand that you are concerned about breaking users, but I've read every single unarchived Debian bug with "mailcap" in the subject, and I'm not aware of anyone complaining about unquoted %-escapes.
The same users you are concerned about would already have most of their rules broken, including from many popular programs like abiword, audacious, emacs, evince, gimp, gvim, mplayer, nautilus, vlc, xine, xpdf.

The existence of such users is also unproven because we currently don't know of an instance of mail user agent (or similar mailcap parser) that actually benefits from quoted %-escapes.
Moreover, even if such mailcap parser exists, quoted %-escapes don't make it any more secure, just more resistant to *accidental* problems, like word splitting on spaces.

No program of the Mozilla family is affected because they don't really implement mailcap, they just use rules as hints to find executables. And I suspect most GUI programs have ditched mailcap in favor of the less insane Desktop Entry Specification.

On the contrary, we do know that mutt and s-nail require unquoted %-escapes, and someone *is* complaining.

> > Unfortunately they decided not to document anything because "I would like to avoid divergence with other platforms"
>
> Fair point, IMHO.

I disagree.
No divergence has been avoided, just hidden. Even within a single platform, mailcap components are incompatible with each other and insecure. You can't make it worse for the users than it is right now.

The mime-support package has an install base of 99.36% (popcon), and there is no way to disable auto generation of mailcap rules, so everyone has them, but inevitably some of them won't work as expected.

More importantly, if certain combinations of mail user agent and rule are used, you can own a machine just by sending a malicious email. And the worst part is: we can't have it fixed, because there's no way to assign responsibility.

My response to the "wait and see" argument is that 20+ years of bad security and inconvenience is enough. Also, the fear of choosing the wrong policy is unfounded because only one policy can be secure.
My response to the "mailcap is dead" argument is "I wish!".
There's no easy way of knowing whether a particular program makes use of mailcap or not, and some useful ones still do.

> > I don't know about Evolution.
>
> That would be important info

I'll try to look into it if I find the time.

> and please don't forget mutt et al.

Mutt and s-nail policy about mailcap quoting is well documented:
http://www.mutt.org/doc/manual/#secure-mailcap
https://www.sdaoden.eu/code-nail.html#37

Happy holidays,
MNZ


Reply to: