Bug #15693

Enigmail Wizard Setup shows up at every Tails session

Added by mercedes508 2018-06-29 14:56:08 . Updated 2018-09-05 16:14:40 .

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

100%

Feature Branch:
bugfix/15693-dont-show-enigmail-wizard-every-time
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Email Client
Deliverable for:

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.

Subtasks

Related issues

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

History

#1 Updated by intrigeri 2018-06-29 15:06:09

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

#2 Updated by intrigeri 2018-06-29 15:06:39

#3 Updated by intrigeri 2018-06-29 17:41:18

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 2018-06-29 18:03:53

OK, so this is caused by some over-enthusiastic changes we made to fix Bug #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 2018-06-29 18:13:03

  • 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 2018-06-30 07:36:54

  • Priority changed from Normal to Elevated

(That’s a regression introduced in 3.8.)

#7 Updated by intrigeri 2018-06-30 08:44:10

  • 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 2018-06-30 16:18:42

  • 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 2018-06-30 23:32:13

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

LGTM

#10 Updated by intrigeri 2018-07-01 07:35:37

  • 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 2018-07-01 09:44:34

  • Status changed from Fix committed to In Progress

Applied in changeset commit:45925bdb135912505ff428b5ae57249f4e6a5c4e.

#12 Updated by intrigeri 2018-07-01 09:44:38

  • Status changed from In Progress to Fix committed

Applied in changeset commit:dd5f62ba52bea4378c56ef600e765c047bab7e21.

#13 Updated by sajolida 2018-07-02 11:38:19

> […] 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 2018-07-03 09:57:16

redmine@labs.riseup.net:
> Issue Bug #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 2018-07-03 14:24:36

> 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 Bug #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 2018-07-03 20:21:30

>> 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 Bug #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 2018-08-08 11:49:01

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

#18 Updated by intrigeri 2018-09-05 16:14:40

  • Status changed from Fix committed to Resolved