qubes-issues
qubes-issues copied to clipboard
QubesOS
Rewrite Thunderbird Qubes extension as a MailExtension
Qubes OS version
Qubes release 4.0 (R4.0)
Affected component(s) or functionality thunderbird-qubes
Brief summary The Qubes integration with Thunderbird uses a legacy extension that will break in Thunderbird 78.
To Reproduce
vim /usr/lib64/mozilla/extensions/*/[email protected]/manifest.json
Expected behavior
No legacy key
Actual behavior
A legacy key is present.
Screenshots N/A
Additional context I am not sure if this is possible, given the need to override core functionality of Thunderbird. We should probably discuss this with Mozilla. Mozilla accepts feature requests for extension APIs, and provides a method (experiments) for implementing workarounds in the meantime. This will be disabled eventually, but not for years.
Solutions you've tried N/A
Relevant documentation you've consulted https://developer.thunderbird.net/add-ons/about-add-ons
Related, non-duplicate issues none
It's on the roadmap. It's plan for ~September. Especially related to the MOSS fund.
Darn! Thunderbird 78 will come out before then, so thunderbird-qubes will be broken.
(I understand that the resources to do it sooner aren't there.)
Darn! Thunderbird 78 will come out before then, so thunderbird-qubes will be broken. (I understand that the resources to do it sooner aren't there.)
will they stop supporting earlier versions with the release of tb78?
@fepitre will we be working with Mozilla to get any new extension APIs needed merged?
Maybe monkey-patching via Mozilla AutoConfig - like https://github.com/girst/LegacyFox - could bridge the gap until the MailExtension rewrite?
Thunderbird 78.3.1 has now been released in the Fedora stable repo, so users on v68 will be automatically updated.
Thunderbird 78.3.1 has now been released in the Fedora stable repo, so users on v68 will be automatically updated.
Landed here after my fedora 32 vm updated today and I got Thunderbird 78 and am no longer able to open attachments in DispVMs. :(
Perhaps a message/announcement to one of the qubes lists is warranted to tell people? This could be considered a security issue (security guard was there and is now gone).
The new PGP system works great with split-gpg however, no issues there.
Perhaps a message/announcement to one of the qubes lists is warranted to tell people?
Sure, I'll send a message to the mailing lists, but unfortunately all I can say is that it's a known issue and link here.
This could be considered a security issue (security guard was there and is now gone).
I don't see how. The Qubes extension is purely for convenience. It’s not required to do anything. You can do everything that the extension does manually. For example, to open an email attachment in a DisposableVM:
- Save the attachment in your email VM.
- Start a DisposableVM.
- In your email VM,
qvm-copythe attachment to the DisposableVM. - In the DisposableVM, open the attachment.
The extension makes this a lot more convenient by automating the process, but it doesn't do anything that you can't do yourself.
Discussion: https://qubes-os.discourse.group/t/thunderbird-qubes-attachments/865/
Actually, an even easier version:
- Save the attachment in your email VM.
- Right-click on the attachment and select "View in DisposableVM."
That is of course also possible. I myself had the extension set to open in DispVM by default, so I only need to click the attachment from within Thunderbird. Luckily I knew Thunderbird had updated, otherwise I would have continued doing so and accidentally opened the attachment inside my mail appvm. Thanks for adding a message to the mailing list, at least now users are warned.
Guess the suggested manual procedure is inconvenient enough so that people will not do it.
So in the end, we'll have less security until someone makes the thunderbird extension work again.
Users of Debian 10 are affected by this problem as well.
Yes, it is a more painful to follow manual steps.
And @andrewdavidwong is missing one step above: deleted the attachment from the email VM
And @andrewdavidwong is missing one step above: deleted the attachment from the email VM
I considered adding that but decided against it because:
- It's not required to view the file in a DisposableVM.
- It's obvious. Users already know that they can delete files they no longer want.
I just upgraded Thunderbird and found the following workaround for the missing plguin (in fact I consider this more than just a workaround because it avoids many cases of inadvertend mis-use of the Mail-VM):
Edit: This workaround contained some mistakes. I fixed them here and posted the approach to the Qubes forum as well (https://qubes-os.discourse.group/t/guide-hardening-your-thunderbird-mail-vm-and-working-around-the-still-missing-qubes-attachments-plugin/1432). If something doesn't work for you, feel free to join the discussion over there (as it's not directly related to the Thunderbird extension itself I suppose we shouldn't flood this issue with more postings about workarounds).
In a Terminal of your mail VM execute the following:
-
sudo cp /usr/share/applications/mimeapps.list /home/user/.config/mimeapps.list -
sudo sed -i "s/=.*/=open_in_dispvm.desktop;/g" /home/user/.config/mimeapps.list
These two commands set an application "open_in_dispvm" as the default value for all mime-types that the system knows about. Now create this application and make it execute anything in a VM of your choice:
-
nano /home/user/.local/share/applications/open_in_dispvm.desktop
Enter the following:
Encoding=UTF-8
Name=Open_in_DispVM
Exec=qvm-open-in-vm <VM_OF_YOUR_CHOICE> %u
Terminal=false
X-MultipleArgs=false
Type=Application
Instead of <VM_OF_YOUR_CHOICE>, specify the name of an existing VM. Now, whenever you click on an application it should call "qvm-open-in-vm" instead of opening it inside of the Mail VM. You could also call qvm-open-in-dvm instead.
Personally, I combine it with a modified RPC-policy in dom0:
- In a dom0 terminal, do
sudo nano /etc/qubes-rpc/policy/qubes.OpenInVM. Replace whatever might be there with<NAME_OF_YOUR_MAIL_VM> $anyvm ask.
That way, every time I try to open anything in the mail VM Qubes does not just use the <VM_OF_YOUR_CHOICE> that I specified in the .desktop-file, but asks me in which VM I want to open it and I can easily redirect everything as I wish:
- something I want to print goes to my print VM
- a hyperlink could be opened in a new dispVM
- or I could choose to open it in an already existing VM
- ...
2\. obvious
Yes, deleting the file obvious, but it is one more step to the process, which makes it less likely to be done.
Of course, leaving the file around is not a security risk, but what is a security risk is deciding that there are too many steps for safety, and then just opening the file in the thunderbird VM. That is what makes this less safe.
Changes in TB78+ requires basically rewriting the extension from scratch. Here are some hints about the new API, including similar extension: https://developer.thunderbird.net/add-ons/updating/tb78 https://github.com/HiraokaHyperTools/OpenAttachmentByExtension/pull/2/files
Looks like we will need to use an experiment for this, as we need to both run external commands (which obviously is only possible from a privileged context) and to override a core part of the Thunderbird UI.
I am going to get in contact with the Thunderbird developers and try and come up with a plan.
@marmarek The API provided by the oabe experiment is sufficient, but it has no chance of being upstreamed, as it allows the extension to execute arbitrary commands. This contradicts one of the major goals of WebExtensions, which is to remove extensions from the trusted computing base.
The sanctioned way for a WebExtension to interact with native code is Native Messaging. Native Messaging requires a host process, which we would need to implement ourselves. Additionally, I am not sure how well an API that changed the default handler for downloads would be received at Mozilla.
Another option is to change the OS file associations ourselves, so that every file opens in a DispVM by default. This is actually a more general approach, since it affects not only Thunderbird but also Nautilus, xdg-open, and any other program that respects file associations.
Another option is to change the OS file associations ourselves, so that every file opens in a DispVM by default.
In case of dedicated qube for mails that should be fine, but I'm afraid it doesn't work for less strict compartmentalization, like generic "work" qube, where you may want to open some files locally.
What are the practical downsides of shipping an extension with oabe experiment included?
None per se, but we will need to rewrite the extension at some point in the future.
Part of this will require some HTML/CSS for the user interface, @andrewdavidwong can you help when @DemiMarie provide details what exactly is needed?
Part of this will require some HTML/CSS for the user interface, @andrewdavidwong can you help when @DemiMarie provide details what exactly is needed?
Yes, I'd be happy to help!
@marmarek @andrewdavidwong I just got some good news from the Thunderbird team: they will be extending the context menu API to include the attachment menu. That makes implementing this much easier.
This won’t happen for another month or so, minimum. Is it worth waiting until then?
The current plan is to replace the Thunderbird extension with a more general system that works for other applications as well. @marmarek can this be closed as “won’t fix”?
We still want at some point an extension adding actions like "save to another qube".