Rewrite Thunderbird Qubes extension as a MailExtension

[DemiMarie]

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/*/qubes-attachment@qubes-os.org/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

[fepitre]

It's on the roadmap. It's plan for ~September. Especially related to the MOSS fund.

[DemiMarie]

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.)

[0spinboson]

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?

[DemiMarie]

@0spinboson Yes, if i understand correctly.

[DemiMarie]

@fepitre will we be working with Mozilla to get any new extension APIs needed merged?

[rustybird]

Maybe monkey-patching via Mozilla AutoConfig - like https://github.com/girst/LegacyFox - could bridge the gap until the MailExtension rewrite?

[mfc]

Edit: My apologies, I was discussing split-gpg compatibility, I have created a new ticket for that.

[Geblaat]

Thunderbird 78.3.1 has now been released in the Fedora stable repo, so users on v68 will be automatically updated.

[abeluck]

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.

[andrewdavidwong]

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:

1. Save the attachment in your email VM.
2. Start a DisposableVM.
3. In your email VM, qvm-copy the attachment to the DisposableVM.
4. 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/

[andrewdavidwong]

Actually, an even easier version:

1. Save the attachment in your email VM.
2. Right-click on the attachment and select "View in DisposableVM."

[Geblaat]

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.

[ThomasWaldmann]

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.

[nereocystis]

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

[andrewdavidwong]

And @andrewdavidwong is missing one step above: deleted the attachment from the email VM

I considered adding that but decided against it because:

1. It's not required to view the file in a DisposableVM.
2. It's obvious. Users already know that they can delete files they no longer want.

[shaaati]

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 , 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 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
• ...

[nereocystis]

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.

[marmarek]

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

[DemiMarie]

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.

[marmarek]

Yes

[DemiMarie]

I am going to get in contact with the Thunderbird developers and try and come up with a plan.

[DemiMarie]

@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.

[marmarek]

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?

[DemiMarie]

None per se, but we will need to rewrite the extension at some point in the future.

[marmarek]

Part of this will require some HTML/CSS for the user interface, @andrewdavidwong can you help when @DemiMarie provide details what exactly is needed?

[andrewdavidwong]

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!

[DemiMarie]

@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.

[DemiMarie]

This won’t happen for another month or so, minimum. Is it worth waiting until then?

[DemiMarie]

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”?

[marmarek]

We still want at some point an extension adding actions like "save to another qube".

[DemiMarie]

Good point. That isn’t critical, though. Lowering priority to “default”.

[nereocystis]

This still seems important to me, even if it can't be fixed for a while. Currently, it is easy to make unsafe decisions. That's a problem.

Yes, it's possible to make safe decisions, but it takes more steps

On January 20, 2021 4:45:40 PM PST, Demi Marie Obenour notifications@github.com wrote:

Good point. That isn’t critical, though. Lowering priority to “default”.>

-- > You are receiving this because you are subscribed to this thread.> Reply to this email directly or view it on GitHub:> https://github.com/QubesOS/qubes-issues/issues/5861#issuecomment-764100732

[DemiMarie]

Update: the needed API will be available in the next stable release of Thunderbird, which is scheduled for November.

[andrewdavidwong]

Another workaround, courtesy of @SvenSemmler in https://github.com/QubesOS/qubes-issues/issues/1121#issuecomment-830442077:

There is the option to add common file types (PDF, Office formats etc) to the "Files & Attachments" preference in Thunderbird and hook it to qvm-open-in-dvm. That works just as well as thunderbird-qubes did for me especially in combination with the 'ask' policy.

I can confirm it works. The annoying part is setting up every file type you need in every Thunderbird VM you need. But, once you've done that, it works exactly the same as the old thunderbird-qubes extension did: Just double click on the attachment in Thunderbird, and it automatically opens in a new DisposableVM.

[mfc]

great workaround! thanks @SvenSemmler

could there be a possibility that instead of the more difficult task we currently have for this issue, we just create an extension or deb / fedora packages that sets the open preferences in Thunderbird to /usr/bin/qvm-open-in-dvm? i would propose for all files types. "Import OpenPGP Key" still works as expected, and if the user doesn't want to open in DVM, they can save the file first.

[DemiMarie]

great workaround! thanks @SvenSemmler

could there be a possibility that instead of the more difficult task we currently have for this issue, we just create an extension or deb / fedora packages that sets the open preferences in Thunderbird to /usr/bin/qvm-open-in-dvm? i would propose for all files types. "Import OpenPGP Key" still works as expected, and if the user doesn't want to open in DVM, they can save the file first.

There is already work in that direction going on. See https://github.com/QubesOS/qubes-core-agent-linux/pull/290.

[mfc]

Another workaround, courtesy of @SvenSemmler in #1121 (comment):

There is the option to add common file types (PDF, Office formats etc) to the "Files & Attachments" preference in Thunderbird and hook it to qvm-open-in-dvm. That works just as well as thunderbird-qubes did for me especially in combination with the 'ask' policy.

I can confirm it works. The annoying part is setting up every file type you need in every Thunderbird VM you need. But, once you've done that, it works exactly the same as the old thunderbird-qubes extension did: Just double click on the attachment in Thunderbird, and it automatically opens in a new DisposableVM.

i'd like to note that even with all content types having the action use qvm-open-in-dvm:

• file
• JPEG image
• Markdown document
• PDF document
• PGP keys
• plain text documents

PNG files are not opened via qvm-open-in-dvm but are opened in the vm with thunderbird. so be careful.

[ilka-schulz]

Qubes R4.1.0 beta now comes with Fedora 34 which comes with Thunderbird 78.11.0. That means a fresh Qubes installation comes with a broken addon.

[andrewdavidwong]

@marmarek, @DemiMarie: Is this expected to be done in time for the 4.1 release, and should it get the release notes label?

[DemiMarie]

@marmarek, @DemiMarie: Is this expected to be done in time for the 4.1 release, and should it get the release notes label?

Probably not. Thunderbird 91 came out only recently, and I am still not sure if it supports the needed APIs.

Qubes R4.1.0 beta now comes with Fedora 34 which comes with Thunderbird 78.11.0. That means a fresh Qubes installation comes with a broken addon.

Fedora ships with an old version of Thunderbird that is behind on security patches. I recommend using Thunderbird in Debian qubes instead, as Debian does a better job of shipping a recent version.

[andrewdavidwong]

@marmarek, @DemiMarie: Is this expected to be done in time for the 4.1 release, and should it get the release notes label?

Probably not. Thunderbird 91 came out only recently, and I am still not sure if it supports the needed APIs.

Ok, I suppose I'll move it to the 4.2 milestone then.

Qubes R4.1.0 beta now comes with Fedora 34 which comes with Thunderbird 78.11.0. That means a fresh Qubes installation comes with a broken addon.

Fedora ships with an old version of Thunderbird that is behind on security patches. I recommend using Thunderbird in Debian qubes instead, as Debian does a better job of shipping a recent version.

Does this mean that the extension works by default in Debian 10+ in Qubes 4.1?

[marmarek]

Indeed, extension rewrite for the new Thunderbird version is not realistic for R4.1. But, what is realistic, is the alternative for opening attachments in DispVM, mentioned at https://github.com/QubesOS/qubes-issues/issues/5861#issuecomment-833122650. It is in final testing phase, and looks to be working okay-ish.

Should we track this feature in separate issue @andrewdavidwong ?

[andrewdavidwong]

Indeed, extension rewrite for the new Thunderbird version is not realistic for R4.1. But, what is realistic, is the alternative for opening attachments in DispVM, mentioned at #5861 (comment). It is in final testing phase, and looks to be working okay-ish.

Should we track this feature in separate issue @andrewdavidwong ?

Yes, sounds good. Opened: https://github.com/QubesOS/qubes-issues/issues/6877

[DemiMarie]

@marmarek, @DemiMarie: Is this expected to be done in time for the 4.1 release, and should it get the release notes label?

Probably not. Thunderbird 91 came out only recently, and I am still not sure if it supports the needed APIs.

Ok, I suppose I'll move it to the 4.2 milestone then.

I consider this to be worth backporting to R4.1 once it does get implemented, even though it won’t be ready for the R4.1 release. Moving to R4.1 updates.

I also recommend dropping the current extension in R4.1, at least if there is a clear way to implement this. Could old versions of the extension be obsoleted by the R4.1 qubes-core-agent package? To avoid confusion, I would prefer to not ship an extension than to ship a broken one.

Qubes R4.1.0 beta now comes with Fedora 34 which comes with Thunderbird 78.11.0. That means a fresh Qubes installation comes with a broken addon.

Fedora ships with an old version of Thunderbird that is behind on security patches. I recommend using Thunderbird in Debian qubes instead, as Debian does a better job of shipping a recent version.

Does this mean that the extension works by default in Debian 10+ in Qubes 4.1?

No, but once Debian 11 ships Thunderbird 91, this task will go from “cannot be implemented in a maintainable fashion” to “should be implementable in a reasonable amount of time using stable APIs”.

[Geblaat]

Note that Thunderbird 91 is now released as stable update on Debian 11.

[DemiMarie]

Turns out that the necessary feature (https://bugzilla.mozilla.org/show_bug.cgi?id=1698357) didn’t make it into Thunderbird 91, but will hopefully be implemented soon-ish and backported.

[DemiMarie]

Marking as S: blocked because this issue is not something that can practically solved before Thunderbird has support for it.

[DemiMarie]

The feature ha

Turns out that the necessary feature (https://bugzilla.mozilla.org/show_bug.cgi?id=1698357) didn’t make it into Thunderbird 91, but will hopefully be implemented soon-ish and backported.

That feature has been implemented, but it won’t be backported, as Thunderbird 102 is expected to be out in late June. Once Thunderbird 102 is out I will be able to fix this.

Moving to “Release R4.0 Updates” as R4.0 will still be supported.

[DemiMarie]

This is no longer blocked, but R4.0 is end of life.

[Geblaat]

Thunderbird 102.2.0 has been released as stable update for Fedora.