Project

General

Profile

Bug #15693

Enigmail Wizard Setup shows up at every Tails session

Added by mercedes508 6 months ago. Updated 3 months ago.

Status:
Resolved
Priority:
Elevated
Assignee:
-
Category:
Persistence
Target version:
Start date:
06/29/2018
Due date:
% Done:

100%

QA Check:
Pass
Feature Branch:
bugfix/15693-dont-show-enigmail-wizard-every-time
Type of work:
Code
Blueprint:
Starter:
Affected tool:
Email Client

Description

Apparently, even if using Thunderbird persistence, Enigmail Wizrd Setup shows up at every boot ot Tails and launch of Thunderbird.

I guess this is not to expect.


Related issues

Related to Tails - Bug #15692: Tell users they have to go through Enigmail Wizard at every session Resolved 06/29/2018
Related to Tails - Bug #15746: Don't display the Enigmail setup wizard by default when starting Thunderbird Resolved 07/22/2018
Blocks Tails - Feature #15334: Core work 2018Q3: Foundations Team Resolved 02/20/2018

Associated revisions

Revision 45925bdb (diff)
Added by intrigeri 6 months ago

Stop deleting Enigmail's persistent configuredVersion (refs: #15693).

Enigmail needs this info to know whether it should display its configuration
wizard and trigger other post-upgrade operations. We should let it manage
this value itself, otherwise it will display its configuration wizard
every time one starts Thunderbird in a freshly booted Tails, even if
the Thunderbird data is persistent.

Revision dd5f62ba
Added by intrigeri 6 months ago

Merge branch 'bugfix/15693-dont-show-enigmail-wizard-every-time' into stable (Fix-committed: #15693)

History

#1 Updated by intrigeri 6 months ago

  • Related to Bug #15692: Tell users they have to go through Enigmail Wizard at every session added

#2 Updated by intrigeri 6 months ago

#3 Updated by intrigeri 6 months ago

Well, well, I messed up: first I noticed the wizard popping up but failed to let sajolida know this should be documented in the release notes. Then I told sajolida about the workaround (just follow the wizard and accept the default choices) but neither he nor myself checked that the workaround actually worked for the next Tails session :/

#4 Updated by intrigeri 6 months ago

OK, so this is caused by some over-enthusiastic changes we made to fix #12680, that have this kind of unintended, over-reaching side effects. Enigmail has logic that seems pretty accurate (package/configure.jsm) to deal with upgrades so IMO we should stop deleting the info it needs to do so, i.e. the real, persisted value of extensions.enigmail.configuredVersion.

#5 Updated by intrigeri 6 months ago

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10
  • Feature Branch set to bugfix/15693-dont-show-enigmail-wizard-every-time

#6 Updated by intrigeri 6 months ago

  • Priority changed from Normal to Elevated

(That's a regression introduced in 3.8.)

#7 Updated by intrigeri 6 months ago

  • Category set to Persistence
  • % Done changed from 10 to 40

Note to the reviewer: I don't think it's worth building and testing an ISO unless I missed something important in the tests I did (see below). So 20 minutes should be more than enough for a thorough code review.

Here's how I tested it:

  1. upgrade account from 3.8
    1. install 3.8 on a USB stick, enable persistence for Thunderbird and GnuPG, reboot, create a key pair, start Thunderbird, go through the account creation and Enigmail wizards
    2. reboot a couple times with persistence enabled and confirm the bug: every time I start Thunderbird I'm shown the Enigmail wizard again
    3. upgrade the USB stick to an ISO build from this branch
    4. reboot
    5. start Thunderbird: the Enigmail wizard is not shown
    6. do the last two steps again, just in case
  2. newly created account
    1. install an ISO built from this branch on a USB stick (deleting its persistent volume)
    2. boot, set up persistent volume with Thunderbird and GnuPG features enabled
    3. reboot, enable persistence, start Thunderbird, go through the account creation and Enigmail wizards
    4. reboot, enable persistence, start Thunderbird: the Enigmail wizard is not shown

And every time I wanted to verify that the Enigmail wizard was not shown, I've waited ~2 minutes: under some circumstances Enigmail will delay its display by 1 minute.

#8 Updated by intrigeri 6 months ago

  • Assignee changed from intrigeri to segfault
  • % Done changed from 40 to 50
  • QA Check set to Ready for QA

Wanna take it? See previous comment that has my notes to the reviewer.

#9 Updated by segfault 6 months ago

  • Assignee changed from segfault to intrigeri
  • QA Check changed from Ready for QA to Pass

LGTM

#10 Updated by intrigeri 6 months ago

  • Status changed from In Progress to Fix committed
  • Assignee deleted (intrigeri)
  • % Done changed from 50 to 100
  • Type of work changed from Research to Code

Thanks! Rebased --onto stable devel (my mistake for having based in ot devel in the first place), removed the "WIP" prefix on the last commit (oversight), merged into stable and devel.

#11 Updated by intrigeri 6 months ago

  • Status changed from Fix committed to In Progress

#12 Updated by intrigeri 6 months ago

  • Status changed from In Progress to Fix committed

#13 Updated by sajolida 5 months ago

[...] neither he nor myself checked that the workaround actually worked for the next Tails session :/

If I remember well you published the release while I was still testing
this :) Maybe it was too big of a change for a point release as several
of us would have detected this in an RC.

#14 Updated by intrigeri 5 months ago

:

Issue #15693 has been updated by sajolida.

[...] neither he nor myself checked that the workaround actually worked for the next Tails session :/

If I remember well you published the release while I was still testing this :)

Right, but that does not change the fact that we've documented a workaround that does not fully work, which is the point I was making; and I'm taking my share of responsibility for that. FTR I would not have rebuilt a new ISO to fix that bug anyway, so the timing of testing the workaround vs. releasing is not relevant.

Maybe it was too big of a change for a point release

Maybe. OTOH it was great time to fix (most of) EFAIL and even with this UX regression, I personally don't regret shipping the fix.

as several of us would have detected this in an RC.

Past experience has made me lose lots of faith in our RCs and in the assumption that our contributors use them.

#15 Updated by sajolida 5 months ago

Maybe. OTOH it was great time to fix (most of) EFAIL and even with this UX regression, I personally don't regret shipping the fix.

I find it quite painful to redo all my Enigmail settings everyday.
Yesterday, I tried to skip some of it to go faster and got bitten by
Schleuder for not signing my emails. Before 3.8, I was not caring about
EFAIL a lot as analyzed on #15602.

But yeah, we don't have to agree on this and the past is the past :)

Past experience has made me lose lots of faith in our RCs and in the assumption that our contributors use them.

At least I use RCs every time and we could maybe clarify with Help desk
and it would be nice if they run them too (I bet some do that already).

#16 Updated by intrigeri 5 months ago

Maybe. OTOH it was great time to fix (most of) EFAIL and even with this UX regression, I personally don't regret shipping the fix.

I find it quite painful to redo all my Enigmail settings everyday. Yesterday, I tried to skip some of it to go faster and got bitten by Schleuder for not signing my emails. Before 3.8, I was not caring about EFAIL a lot as analyzed on #15602.

I stand corrected in many ways. Thanks!

Past experience has made me lose lots of faith in our RCs and in the assumption that our contributors use them.

At least I use RCs every time and we could maybe clarify with Help desk and it would be nice if they run them too (I bet some do that already).

Good to know!

#17 Updated by intrigeri 4 months ago

  • Related to Bug #15746: Don't display the Enigmail setup wizard by default when starting Thunderbird added

#18 Updated by intrigeri 3 months ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF