Repository: freedomofpress/securedrop

Issue:
[qt-journalist-updater] Add a time estimate to the update progress bar
## Description

[See epic #3076 for primary feature, PRs for this ticket should go into `qt-journalist-updater`]

We should add a reasonable time estimate to the update progress bar as the upgrade progresses

## User Stories

As a journalist user, I want an estimate of how long it will take until updates are finished so that I can plan. 


Discussion:
Here's a breakdown of the time taken at each step (from testing in a Tails VM):

1. **Check out latest tag** - this takes less than a minute once connected to Tor. Note that since the updater GUI does not launch unless we are already connected to Tor, we don't need to know the (variable) time that takes. 

2. **Verify signature** - this doesn't take long for the happy path - less than a minute to update the key and verify the signature. However, if we hit the bug in #3243 it takes ~8 minutes for `gpg --recv-key` to timeout:

```
amnesia@amnesia:~/Persistent/securedrop$ time gpg --keyserver freedom.press --recv-key "2224 5C81 E3BA EB41 38B3 6061 310F 5612 00F4 AD77"
gpg: keyserver receive failed: Connection timed out

real	8m7.564s
user	0m0.004s
sys	0m0.000s
``` 

So, when we fix #3243 (we needed to fix this bug in 0.7 anyway), we should implement a timeout such that this command fails more rapidly to keep the timing consistent (I think within a minute is reasonable). `subprocess` in Python 3 has `timeout` functionality, but since `securedrop-admin` is in Python 2 we can do something like [this](https://www.blog.pythonlibrary.org/2016/05/17/python-101-how-to-timeout-a-subprocess/) instead.

3. **Tails configuration** - this takes ~30 seconds or less. 

As such, the suggested times for showing in the updater for each step are:

1. "Approx. 4 minutes remaining"
2. "Approx. 3 minutes remaining" (taking the max here because if we try an alternate keyserver it will take a bit longer. As a user I expect to be pleasantly surprised if my update takes 1 minute shorter than expected, but slightly annoyed if my update takes 1 minute longer than expected).
3. "Approx. 1 minute remaining"

Precision of about a minute or so seems reasonable for the user feedback (user testing will tell us if this assumption is valid), and I'm not aware of any sources of additional variability (barring a failure somewhere in the updater) beyond what is described in step 2. 

Resolving patch:
diff --git a/journalist_gui/journalist_gui/strings.py b/journalist_gui/journalist_gui/strings.py
--- a/journalist_gui/journalist_gui/strings.py
+++ b/journalist_gui/journalist_gui/strings.py
@@ -2,8 +2,10 @@
 update_in_progress = ("SecureDrop workstation updates are available! "
                       "You should install them now. If you don\'t want to, "
                       "you can install them the next time you reboot.")
-fetching_update = 'Fetching and verifying latest update...'
-updating_tails_env = 'Configuring local Tails environment...'
+fetching_update = ('Fetching and verifying latest update...'
+                   ' (4 mins remaining)')
+updating_tails_env = ('Configuring local Tails environment...'
+                      ' (1 min remaining)')
 finished = 'Update successfully completed!'
 finished_dialog_message = 'Updates completed successfully. Click OK to close.'
 finished_dialog_title = 'SecureDrop Workstation is up to date!'


Test patch: