Project

General

Profile

Bug #16422

Upgrade Thunderbird to 60.5.1

Added by intrigeri 8 months ago. Updated 7 months ago.

Status:
Resolved
Priority:
Elevated
Category:
-
Target version:
Start date:
02/05/2019
Due date:
% Done:

70%

Feature Branch:
bugfix-16422-thunderbird-60.5.1, icedove:bugfix/16422-thunderbird-60.5.1
Type of work:
Code
Blueprint:
Starter:
Affected tool:
Email Client

Related issues

Related to Tails - Bug #16529: Thunderbird: jsconsole is broken Resolved 03/05/2019
Related to Tails - Bug #16570: Fix the secure Thunderbird autoconfig wizard patchset Rejected 03/18/2019
Related to Tails - Bug #16573: Thunderbird autoconfig broken since 60.5.1 Resolved 03/19/2019
Blocks Tails - Feature #15507: Core work 2019Q1: Foundations Team Resolved 04/08/2018
Blocks Tails - Feature #16045: Clean-up: remove obsolete Thunderbird check Resolved 10/12/2018
Blocks Tails - Bug #16555: Thunderbird "my Thunderbird inbox is non-empty" test consistently fails Resolved 03/14/2019

Associated revisions

Revision f3081528 (diff)
Added by CyrilBrulebois 7 months ago

Enable the bugfix-16422-thunderbird-60.5.1 overlay (refs: #16422).

Revision c8822e9d (diff)
Added by CyrilBrulebois 7 months ago

Refresh apparmor-adjust-thunderbird-profile.diff for TB 65.1.0 (refs: #16422).

The context of the third hunk changed:

-   @{thunderbird_executable} ixr,
+ /usr/lib/thunderbird/thunderbird{,-bin} ixr,

Revision b02cfe43 (diff)
Added by CyrilBrulebois 7 months ago

Test suite: adapt for Thunderbird 60.5.1 (refs: #16422).

Headers are now gathered as a list instead of a table row, so fetching
all table rows without recursion returns only messages; drop the shift
accordingly.

Revision f1078a80 (diff)
Added by intrigeri 7 months ago

Take into account pref rename in Thunderbird autoconfig patchset (refs: #16422)

The update #6156 patchset renamed
mailnews.auto_config.account_constraints.ssl_only pref to
mailnews.auto_config.ssl_only_mail_servers. Let's set both.

Also, remove obsolete comment claiming that this is the default:
as of thunderbird 60.5.1-1~deb9u1.0tails1,
mailnews.auto_config.ssl_only_mail_servers is set to false by default.

Revision 606b1dd2 (diff)
Added by intrigeri 7 months ago

Drop custom Thunderbird package (refs: #16422)

It breaks the account setup wizard at least with some email providers.
For details, see #16422#note-24.

Revision 26c95a09 (diff)
Added by CyrilBrulebois 7 months ago

Refresh apparmor-adjust-thunderbird-profile.diff for TB 65.1.0 (refs: #16422).

The context of the third hunk changed:

-   @{thunderbird_executable} ixr,
+ /usr/lib/thunderbird/thunderbird{,-bin} ixr,

Revision b109a7d2 (diff)
Added by CyrilBrulebois 7 months ago

Test suite: adapt for Thunderbird 60.5.1 (refs: #16422).

Headers are now gathered as a list instead of a table row, so fetching
all table rows without recursion returns only messages; drop the shift
accordingly.

Revision 21ae46a0 (diff)
Added by CyrilBrulebois 7 months ago

Refresh apparmor-adjust-thunderbird-profile.diff for TB 65.1.0 (refs: #16422).

The context of the third hunk changed:

-   @{thunderbird_executable} ixr,
+ /usr/lib/thunderbird/thunderbird{,-bin} ixr,

History

#1 Updated by intrigeri 8 months ago

#2 Updated by CyrilBrulebois 8 months ago

  • Assignee set to CyrilBrulebois

#3 Updated by intrigeri 8 months ago

Looks like this will require refreshing config/chroot_local-patches/apparmor-adjust-thunderbird-profile.diff: https://jenkins.tails.boum.org/job/build_Tails_ISO_feature-buster/581/console

#4 Updated by intrigeri 8 months ago

  • Subject changed from Upgrade Thunderbird to 60.5 to Upgrade Thunderbird to 60.5.1

(It's now public info that there will be a 60.5.1.)

#5 Updated by CyrilBrulebois 7 months ago

I'm working on this and initial investigations suggest it will likely take more than the usual 2 hours. Expecting up to 4 hours (maybe more with some testing), due to some needed rework for a bunch of the secure-account-creation patches.

@intrigeri: ACK regarding the extended time budget?

#6 Updated by intrigeri 7 months ago

ACK regarding the extended time budget?

@CyrilBrulebois, yes. Note that @anonym has recently sent an updated set of patches upstream (probably based on something more recent than 60.x though) so it might be that some of this patch reworking has been done already. It would be great if you managed to coordinate with him but don't block on this for too long :)

#7 Updated by intrigeri 7 months ago

Also, note that 60.5.3 is ready upstream. I don't know if it has changes we want nor when Carsten will package it.

#8 Updated by CyrilBrulebois 7 months ago

OK, thanks, will prod by mail too.

60.5.3's release notes seem to be mostly about: “Problem when using "Send to > Mail recipient" on Windows introduced in version 60.5.2.”

60.5.2's release notes seem to be about Windows issues mostly, except for S/MIME support. Do we support that? → “Problem with S/MIME certificate verification when receiving email from Outlook (issue introduced in version 60.5.1)”

#9 Updated by intrigeri 7 months ago

except for S/MIME support. Do we support that?

We explicitly support OpenPGP in Thunderbird but we don't support S/MIME ⇒ ignore the S/MIME issues and proceed :)

#10 Updated by hefee 7 months ago

  • Related to Bug #16529: Thunderbird: jsconsole is broken added

#11 Updated by intrigeri 7 months ago

  • Related to Bug #16555: Thunderbird "my Thunderbird inbox is non-empty" test consistently fails added

#12 Updated by CyrilBrulebois 7 months ago

  • Assignee changed from CyrilBrulebois to anonym
  • QA Check set to Ready for QA
  • Feature Branch set to icedove:bugfix/16422-thunderbird-60.5.1

Finally finished adapting patches from the tails/secure_account_creation-66.0_b1 branch, currently building; will be testing shortly.

@anonym: is there any chance you could have a look at the topic branch please? Hopefully I didn't break your patches by refreshing them, but the more eyes the better…

#13 Updated by CyrilBrulebois 7 months ago

  • Assignee deleted (anonym)

Removing assignment for the time being.

Current status: I've put my locally built packages on a custom webserver, pointed my Tails build forked off from stable to it, and adjusted the thunderbird apparmor patch as needed. The resulting image almost passes the features/thunderbird.feature test suite, except for this part:

Failing Scenarios:
cucumber features/thunderbird.feature:42 # Scenario: Thunderbird can download the inbox with POP3

Looking at the screenshot/video, it looks to me that the test actually succeeded, and that the test suite might need an update; I'll investigate that shortly. In the meanwhile, I'll prepare a final build (on a trusted but slower machine this time) of Thunderbird, and upload it to our custom repository; and update/push the tails.git branch accordingly.

#14 Updated by CyrilBrulebois 7 months ago

  • Status changed from Confirmed to In Progress

#15 Updated by CyrilBrulebois 7 months ago

  • Assignee set to intrigeri

And there's bugfix-16422-thunderbird-60.5.1 in tails.git as well now. Should be an easy review since that's mostly an overlay addition, but that's also my first time doing so, so I'd be happy to get a “LGTM” from someone else.

I've managed to fix the test suite thanks to accerciser, and learned a bit more about how to print debug information in the process (I struggled a bit with Dogtail::Node objects initially…).

#16 Updated by intrigeri 7 months ago

  • Feature Branch changed from icedove:bugfix/16422-thunderbird-60.5.1 to bugfix-16422-thunderbird-60.5.1, icedove:bugfix/16422-thunderbird-60.5.1

#17 Updated by intrigeri 7 months ago

The resulting image almost passes the features/thunderbird.feature test suite, except for this part:

@CyrilBrulebois, that's #16555. Glad you found a fix for it!

#18 Updated by intrigeri 7 months ago

@CyrilBrulebois, code review passes except one thing:

It looks like the mailnews.auto_config.account_constraints.ssl_only pref was renamed to mailnews.auto_config.ssl_only_mail_servers in the updated patchset. In config/chroot_local-includes/etc/thunderbird/pref/thunderbird.js we're setting the former but not the latter, so I think that on this branch, we haven't enabled 100% of the things we expect to get out of anonym's #6156 patchset. I've renamed this pref on the topic branch; now building, then will run thunderbird.feature and report back here.

#19 Updated by intrigeri 7 months ago

I've managed to fix the test suite thanks to accerciser, and learned a bit more about how to print debug information in the process (I struggled a bit with Dogtail::Node objects initially…).

Congrats \o/

#20 Updated by intrigeri 7 months ago

  • Blocks Feature #16045: Clean-up: remove obsolete Thunderbird check added

#21 Updated by intrigeri 7 months ago

  • Related to deleted (Bug #16555: Thunderbird "my Thunderbird inbox is non-empty" test consistently fails)

#22 Updated by intrigeri 7 months ago

  • Blocks Bug #16555: Thunderbird "my Thunderbird inbox is non-empty" test consistently fails added

#23 Updated by intrigeri 7 months ago

  • % Done changed from 0 to 60

intrigeri wrote:

I've renamed this pref on the topic branch; now building, then will run thunderbird.feature and report back here.

thunderbird.feature passes. Will now test manually with & without persistence, using a non-Riseup email account, and then if happy I'll reassign to you for QA.

#24 Updated by intrigeri 7 months ago

Will now test manually with & without persistence, using a non-Riseup email account

@CyrilBrulebois, unfortunately I see a regression in the account wizard. I first see "Configuration found at email provider" with correct settings, so far so good; on Tails 3.12.1 the wizard would (correctly) stop here. But on this branch, then the wizard keeps trying other things (at least "Looking up configuration: Trying common server names") and ends up telling me "Thunderbird failed to find the settings for your email account" and pre-filling the config settings with imap.$DOMAIN and smtp.$DOMAIN, that won't work in this case.

With pristine 1:60.5.1-1~deb9u1 I see the same buggy behaviour except one important thing: while I do see "Thunderbird failed to find the settings for your email account", the pre-filled config settings are the correct ones fetched from the email provider, so clicking "Done" is enough to get a working account.

So it seems that Thunderbird 60.5.1 brings part, but not all, of the regression (the wizard keeps looking in other sources after it has already found settings in an authoritative place, and then it gives confusing error feedback to the user while everything is configured just fine). And the other part of the regression seems to be brought either by the latest patchset prepared by anonym (if he tested only with Riseup account, he may have missed this problem: imap.riseup.net and smtp.riseup.net will work), or by the backporting to 60.5.1.

In any case, I think it's too late to try and fix the patchset in time for 3.13 so IMO our best option at this point is to:

  1. Drop the patchset, ship 1:60.5.1-1~deb9u1 from Debian in Tails 3.13. I'll prepare a branch right away.
  2. File a ticket about this for 3.14 (and if we're fast enough there + unlucky enough to have to release 3.13.1 after Pwn2Own, this could actually be fixed within a week or two instead of in 2 months).
  3. Document the known issue in the release notes.

#25 Updated by intrigeri 7 months ago

  • Related to Bug #16570: Fix the secure Thunderbird autoconfig wizard patchset added

#26 Updated by intrigeri 7 months ago

  • Assignee changed from intrigeri to CyrilBrulebois
  • % Done changed from 60 to 70
  • Feature Branch changed from bugfix-16422-thunderbird-60.5.1, icedove:bugfix/16422-thunderbird-60.5.1 to bugfix/16422-thunderbird-60.5.1-debian

intrigeri wrote:

Drop the patchset, ship 1:60.5.1-1~deb9u1 from Debian in Tails 3.13. I'll prepare a branch right away.

Done. The aforementioned Thunderbird 60.5.1 account wizard bug breaks the "Thunderbird can send emails, and receive emails over IMAP" and "Thunderbird can download the inbox with POP3" test suite scenarios. I don't want to block the release process on that so I've successfully tested these cases by hand:

  • non-Riseup account ("Configuration found at email provider")
    • IMAP: account setup, sending and receiving email
    • POP3: account setup, sending and receiving email
  • Riseup account ("Configuration found on Thunderbird installation")
    • IMAP: account setup, sending and receiving email
    • POP3: account setup, sending and receiving email

And while I was at it, I went through the Enigmail setup wizard and successfully sent an encrypted+signed email.

We should probably file a ticket for the test suite issue but I'd rather wait a bit and see what happens on #16570: if that one is fixed, the test suite update would need reverting and we'll have wasted time.

@CyrilBrulebois, please review and merge if happy.

File a ticket about this for 3.14 (and if we're fast enough there + unlucky enough to have to release 3.13.1 after Pwn2Own, this could actually be fixed within a week or two instead of in 2 months).

#16570

Document the known issue in the release notes.

kibi, I'll let you mention this to sajolida when you'll give him info that should be in the release notes.

#27 Updated by anonym 7 months ago

Looking at the branch I see no changes to any prefs. This is concerning because the new patch series changes many of the pref names (upstream request) so you probably tested something strange. It's unclear how this will have effected your test results, but my guess is that it didn't affect and your tests are still good.

intrigeri wrote:

Will now test manually with & without persistence, using a non-Riseup email account

CyrilBrulebois, unfortunately I see a regression in the account wizard. I first see "Configuration found at email provider" with correct settings, so far so good; on Tails 3.12.1 the wizard would (correctly) stop here. But on this branch, then the wizard keeps trying other things (at least "Looking up configuration: Trying common server names") and ends up telling me "Thunderbird failed to find the settings for your email account" and pre-filling the config settings with imap.$DOMAIN and smtp.$DOMAIN, that won't work in this case.

I noticed this myself when I was rebasing and partly rewriting the patch set for Thunderbird 66 but only in a odd edge case: I tested against ProtonMail whose config points to servers at 127.0.0.1 (I suppose you are supposed to run some local proxy to ProtonMail). Thunderbird would consider it a success in the GUI as soon as a valid config is fetched, but would fail after a few seconds when it tries the config (since we don't run any mail servers on 127.0.0.1 and even block any such connection attempt), and then fallback to the remaining auto-config methods that still are running in the background. The fix is to no consider a config successful (not even in the GUI!) until it has been tested.

Care to share which service you tried with so I can investigate if it's similar?

With pristine 1:60.5.1-1~deb9u1 I see the same buggy behaviour except one important thing: while I do see "Thunderbird failed to find the settings for your email account", the pre-filled config settings are the correct ones fetched from the email provider, so clicking "Done" is enough to get a working account.

Interesting! How many times did you reproduce this?

Also note this patch from our series:

    Invalidate config when restarting autoconfiguration.

    Otherwise residual data from previous attempts can leak into following
    attempts, e.g.:

    1. Try "a@a.a" 
    2. All methods fail, so we end up in "manual edit" mode
    3. Note that Server hostname == "a.a", which is expected
    4. Then start over by changing the email to "b@b.b" 
    5. All methods fail, so we end up in "manual edit" mode
    6. Note that Server hostname == "a.a", but should be "b.b" 

So I hope you didn't trigger that bug in a very unlucky scenario with the non-patched Thunderbird.

I also wonder if the prefs descrepency could cause problems with your test, but I sort of doubt it and think a bug in my patches is more likely.

So it seems that Thunderbird 60.5.1 brings part, but not all, of the regression (the wizard keeps looking in other sources after it has already found settings in an authoritative place, and then it gives confusing error feedback to the user while everything is configured just fine). And the other part of the regression seems to be brought either by the latest patchset prepared by anonym (if he tested only with Riseup account, he may have missed this problem: imap.riseup.net and smtp.riseup.net will work), or by the backporting to 60.5.1.

This is my "test suite" to cover the auto-config methods we care about:

  • → 'Configuration found on Thunderbird installation'
  • → 'Configuration found at email provider'
  • → 'Configuration found in Mozilla ISP database'
  • → 'Configuration found by trying common server names' (they serve a .well-known config over insecure http only, so in Tails we won't fetch it since we require https, and get protocol guessing instead)

Since Thunderbird 60.5.1/66 makes all auto-config methods run in parallel you might have to rerun tests to get the expected result.

In any case, I think it's too late to try and fix the patchset in time for 3.13 so IMO our best option at this point is to:

  1. Drop the patchset, ship 1:60.5.1-1~deb9u1 from Debian in Tails 3.13. I'll prepare a branch right away.

Ack! However...

☣️☠⚠️ Please also disable the auto-configuration wizard! ⚠️☠☣️

By default auto-configuration is catastrophically unsafe (after all, that is why the patch series exist in the first place), and protocol guessing is broken since it bypasses the proxy configuration => blocked. Sadly, since our IMAP/POP/SMTP using Thunderbird scenarios arrive there by using the configuration wizard, these tests will have to be removed until we can safely enable the wizard again.

Implementation hint: in config/chroot_local-includes/etc/xul-ext/torbirdy.js set extensions.torbirdy.emailwizard to false.

#28 Updated by intrigeri 7 months ago

  • Feature Branch changed from bugfix/16422-thunderbird-60.5.1-debian to bugfix-16422-thunderbird-60.5.1, icedove:bugfix/16422-thunderbird-60.5.1

Looking at the branch I see no changes to any prefs. This is concerning because the new patch series changes many of the pref names (upstream request)

I suspect you're looking at my new branch, that hasn't the prefs changes (no need to adjust prefs to an updated patchset that we don't ship). bugfix-16422-thunderbird-60.5.1 is probably what you're looking for.

anonym wrote:

intrigeri wrote:

CyrilBrulebois, unfortunately I see a regression in the account wizard. […]

I noticed this myself […]

Replied on #16570.

With pristine 1:60.5.1-1~deb9u1 I see the same buggy behaviour except one important thing: while I do see "Thunderbird failed to find the settings for your email account", the pre-filled config settings are the correct ones fetched from the email provider, so clicking "Done" is enough to get a working account.

Interesting! How many times did you reproduce this?

At least 5 times over 5 tries (3 tries with a non-Riseup account, 2 tries with a Riseup account).

  1. Drop the patchset, ship 1:60.5.1-1~deb9u1 from Debian in Tails 3.13. I'll prepare a branch right away.

Ack! However...

☣️☠⚠️ Please also disable the auto-configuration wizard! ⚠️☠☣️

By default auto-configuration is catastrophically unsafe (after all, that is why the patch series exist in the first place), and protocol guessing is broken since it bypasses the proxy configuration => blocked.

Thanks for reminding me the obvious!

Now, if we do that, then the resulting UX, compared to 60.5.1-1~deb9u1.0tails1, will be:

  • domains whose support is hard-coded in Torbirdy (GMail, Riseup, systemli): probably slightly better in some cases and the same in other cases; but I didn't test this
  • any other domain: much worse, i.e. the user has to configure everything by hand, while with 60.5.1-1~deb9u1.0tails1, at least in some cases, the wizard would get it right

Given the only point of reverting to the 60.5.1-1~deb9u1 package from Debian (without the patchset) was to avoid a UX regression, I don't think we should solve the security regression my proposal would bring by implementing a solution on top of it that would make UX even worse in most cases.

So I'm taking back my proposal to ship 60.5.1-1~deb9u1 ⇒ kibi, please review and merge the updated bugfix-16422-thunderbird-60.5.1 branch.

#29 Updated by anonym 7 months ago

intrigeri wrote:

anonym wrote:

intrigeri wrote:

With pristine 1:60.5.1-1~deb9u1 I see the same buggy behaviour except one important thing: while I do see "Thunderbird failed to find the settings for your email account", the pre-filled config settings are the correct ones fetched from the email provider, so clicking "Done" is enough to get a working account.

Interesting! How many times did you reproduce this?

At least 5 times over 5 tries (3 tries with a non-Riseup account, 2 tries with a Riseup account).

I had a quick look. The config is fetched from the ISP (autistici) just fine, but an exception is thrown (TypeError: radiogroup is null, yet to be investigated) invalidating it => fallback to protocol guessing. This happens both with our patches and without, so it's an upstream bug. The difference is that without our patches protocol guessing will fail immediately and some how the server settings from the invalidated config is kept, but with our patches the guessing will initiate and fail after exhaustive testing, and when it fails like that it settles on exactly ${PROTOCOL}.${EMAILDOMAIN} (e.g. imap.boum.org, yeah it extracted the domain straight from the provided email address).

So our patches might not have a bug after all! :)

So I'm taking back my proposal to ship 60.5.1-1~deb9u1 ⇒ kibi, please review and merge the updated bugfix-16422-thunderbird-60.5.1 branch.

Yeah, that makes most sense.

#30 Updated by CyrilBrulebois 7 months ago

  • QA Check changed from Ready for QA to Pass

The extra commit for the config item rename looks good to me, thanks for catching that…

#31 Updated by CyrilBrulebois 7 months ago

  • Status changed from In Progress to Fix committed

Missing # before the ticket number, but fix committed in this merge commit: 857fbb06987facafc571d65dfcba634c4660eedf

#32 Updated by anonym 7 months ago

  • Related to Bug #16573: Thunderbird autoconfig broken since 60.5.1 added

#33 Updated by CyrilBrulebois 7 months ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF