Opened 4 months ago

Last modified 3 weeks ago

#31341 new defect

TorBirdy does not support Thunderbird 68

Reported by: ozozoz Owned by: sukhbir
Priority: Medium Milestone:
Component: Applications/TorBirdy Version:
Severity: Normal Keywords: TorBirdy, Thunderbird 68
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

TorBirdy 0.2.6 could not be installed because it is not compatible with Thunderbird 68. I tested this with Thunderbird 68.0b5.

Child Tickets

Change History (7)

comment:1 Changed 8 weeks ago by arma

I closed #31773 as a duplicate.

Alas, I think it might be a while until torbirdy gets an update -- it involves somebody looking at Thunderbird 68 to see what new privacy invasive problems they put into it.

Maybe you, yes the person reading this ticket, want to take this on?

comment:2 Changed 5 weeks ago by cypherpunks

I would be interested in TorBirdy for Thunderbird 68.x, too. It is a great add-on (thank you very much for providing it); unfortunately, I have no experience in add-on development.

comment:3 Changed 4 weeks ago by cypherpunks

Similar situation here, it seems just now all Debian stable (Buster) installations have received the upgrade to TBird 68, leaving many many former TorBirdy users at risk, myself included.

How will Tails handle the situation? They've always relied on TorBirdy and they are now on Buster, maybe they can fix it in no time and make it available to all of us?

comment:4 Changed 3 weeks ago by sajolida

Our plan at Tails is to get rid of TorBirdy without loosing security features:

https://redmine.tails.boum.org/code/issues/17219

comment:5 Changed 3 weeks ago by cypherpunks

So, where does this leave regular TorBirdy users?

Anyone able and willing to take on the following workaround?

Thunderbird 68 already only supports MailExtensions, but legacy extensions can supposedly be converted to MailExtensions relatively easily: It requires converting the old RDF manifest to a JSON manifest, and then in the JSON manifest the legacy key can be used to load the legacy XUL extension.
https://developer.thunderbird.net/add-ons/tb68
https://developer.thunderbird.net/add-ons/tb68/overlays

(via https://redmine.tails.boum.org/code/issues/17219)

Last edited 3 weeks ago by cypherpunks (previous) (diff)

comment:6 Changed 3 weeks ago by cypherpunks

I just stumbled across this, too, since Thunderbird connects to mail provider(s) directly if TorBirdy was deactivated after upgrading to Thunderbird 68.x .

comment:7 in reply to:  5 Changed 3 weeks ago by u451f

Replying to cypherpunks:

So, where does this leave regular TorBirdy users?

Anyone able and willing to take on the following workaround?

Thunderbird 68 already only supports MailExtensions, but legacy extensions can supposedly be converted to MailExtensions relatively easily: It requires converting the old RDF manifest to a JSON manifest, and then in the JSON manifest the legacy key can be used to load the legacy XUL extension.
https://developer.thunderbird.net/add-ons/tb68
https://developer.thunderbird.net/add-ons/tb68/overlays

I guess the most important part of this comment was that one:

"I looked through the MailExtensions […] API of both Thunderbird 68, and the pre-release version, and didn't see any functions which would allow us to set the preferences set by TorBirdy"

So basically even if one would convert the manifest, the legacy extension would have no way to set the preferences needed to make Torbirdy work.

This is very sad and the options I see for the non-Tails Torbirdy usecase is

  • to check which are the preferences that still make sense with the new Thunderbird:
    • some issues have been mitigated by Tails' patches that were merged
    • some might have been mitigated by their total code rewrite
    • some new issues might have been introduced
  • to check with Thunderbird upstream directly if they are willing to implement those by default, or if they can provide an API endpoint into which an extension can hook into
  • manually change Thunderbird's preferences: basically what Tails will now do.

The two first options require time, communication skills and workforce, the latter is a more pragmatic "let's make it work" approach.

Note: See TracTickets for help on using tickets.