Handle Thunderbird as a special case for mail with attachment.

[nteodosio]

Thunderbird no longer accepts attachments in the mailto URI, it just ignores them. This breaks Nautilus right-click > Email, for example. More context: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2431.

Creates a special case for Thunberbird then, using the -compose option.

Note: This is essentially a smaller diff than it looks, but the indentation level change makes it seem larger. For reference, the patch without indentation level changes.

[nteodosio]

Ah so g_string_free_and_steal is only for Glib >2.76, while Ubuntu 22.04 is on 2.72. I'll rewrite that bit then.

[jadahl]

Special casing apps this way is not reasonable IMO. If Thunderbird stopped supporting mailto as command line argument, then you need to create a compatibility wrapper that handles this, and make that the entry point for the mailto: hander call. This wrapper thing would either be shipped by thunderbird, or by the package (flatpak or snap), thus need no special casing in all possible portals.

[seb128]

Special casing apps this way is not reasonable IMO. If Thunderbird stopped supporting mailto as command line argument, then you need to create a compatibility wrapper that handles this, and make that the entry point for the mailto: hander call. This wrapper thing would either be shipped by thunderbird, or by the package (flatpak or snap), thus need no special casing in all possible portals.

The point of not handling 'attachment=' in mailto: is to avoid making it too easy to trick users into attaching a file without noticing. Imagine a website with a 'contact us for free trial' link which points to a 'mailto:...attachement=~/.ssh/.id_rsa'....

https://www.nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2020/08/15/mailto-paper.pdf has some reference to the issue

Adding a wrapper that would make attachment in mailto work again would just add back the vulnerability.

The problem existed in evolution (CVE-2011-3201) and was fixed there by blocking attachments from /etc and hidden directories but it's somewhat fragile (you can have private content outside of those paths) and not a solution thunderbird (and some other mailers) were comfortable using.

Thunderbird is not likely to change and a popular email client for linux users...

[jadahl]

I thought this was only about missing mailto: not about attachment. Automagic attachments must not be supported indeed.

[seb128]

Sorry the PR description is probably missing some context, the problem is discussed in more details in https://gitlab.gnome.org/GNOME/nautilus/-/issues/2431

but basically the issue is that the way the portal add attachements today is by constructing a 'mailto:....attachement=' url and calling the mail client on it, which is incompatible with thunderbird, which makes the nautilus sendto feature just not work with thunderbird. One alternative would be to hide the 'sendto' entry from nautilus when the default mailer is thunderbird (or another client not handling the mailto scheme for attachements)

[nteodosio]

I apologize, the description was not indeed correctly contextualized.

I edited the main comment with the link from seb128 for better visibility.

[ebassi]

Drive-by comment: the coding style is all over the place, and does not match the existing one. Please, use a style consistent with the rest of the file you're modifying.

[jadahl]

I've a bit the same concerns regarding the hardcoding app-special cases into the portal.

Indeed, we should not do that.

One alternative would be to hide the 'sendto' entry from nautilus when the default mailer is thunderbird (or another client not handling the mailto scheme for attachements)

Maybe sendto should be removed from nautilus if attachments via mailto: is considered dangerous?

[jadahl]

Adding a wrapper that would make attachment in mailto work again would just add back the vulnerability.

How would it be different adding a wrapper doing what this PR is doing, but inside the Thunderbird snap/flatpak?

[nteodosio]

Please, use a style consistent with the rest of the file you're modifying.

Pardon that, I took note of 3v1n0's comment on that but given the low probability of the changes being merged I didn't act on it yet.

How would it be different adding a wrapper doing what this PR is doing, but inside the Thunderbird snap/flatpak?

That should work, but I'm afraid that would have to be done for all forms of packaging, correct?

[seb128]

How would it be different adding a wrapper doing what this PR is doing, but inside the Thunderbird snap/flatpak?

Hum, what would the wrapper do exactly? If we add a script that 'translate' a mailto: url including an attachment to one not including one and appending the option to the cmdline instead then we would restore the problem that a click on a url from a website would allow to attach a filename no? Or we would need from the wrapper to be able to tell what is the caller and only allow that if it's nautilus...

[jadahl]

Hum, what would the wrapper do exactly?

Isn't translating mailto into something Thunderbird understands exactly what is attempted to be introduced here?

The callee won't know who the caller is, no, so it's not possible to "allow list" nautilus in Thunderbird, so I guess if that was the intention, it wont work. Allow listing doesn't seem like a sane solution either way. So it seems like nautilus send-to feature relies on a feature that has potentially significant security implications, and perhaps best to not do that anymore at all.

[seb128]

Isn't translating mailto into something Thunderbird understands exactly what is attempted to be introduced here?

yes, but the point is that we want to do it only for safe callers. Thinking about it more though the current patch wouldn't achieve that either since it's not checking the caller, and such is not really different from the wrapper (it works in our case only because firefox doesn't use the portal atm).

It seems either nautilus should drop the option or go back to have custom code rather than relying on the portal...

[jadahl]

If a sandboxed nautilus can use custom Thunderbird specific code to make it compose an E-mail with a predetermined attachment, what'd stop any other app from doing the same? Or is your assumption that nautilus is outside the sandbox?

[seb128]

If a sandboxed nautilus can use custom Thunderbird specific code to make it compose an E-mail with a predetermined attachment, what'd stop any other app from doing the same? Or is your assumption that nautilus is outside the sandbox?

I was speaking about the case outside the sandbox (I don't know if any distribution provides nautilus sandboxed today, that has other challenges for a filemanager that users would probably expect to tbe able to access any part of their filesystem). But yes, once sandboxed it has no way to invoke the email client

[jadahl]

Sounds like the best long term solution is to drop support for "Send file" via E-mail from file managers then.

[nteodosio]

At least from the user perspective that seems like a nice and reasonable feature to have. The typical thing even Windows XP already had, it looks like a small but solid step back to drop that.

Especially if we consider e.g. Evolution, that warns about the attachment instead of preventing it.