Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prompt users to fix upgrade issue for Tails 4.14 - 4.18 (or fix it for them?) #6098

Closed
rocodes opened this issue Sep 20, 2021 · 5 comments · Fixed by #6110
Closed

Prompt users to fix upgrade issue for Tails 4.14 - 4.18 (or fix it for them?) #6098

rocodes opened this issue Sep 20, 2021 · 5 comments · Fixed by #6110
Assignees
Milestone

Comments

@rocodes
Copy link
Contributor

rocodes commented Sep 20, 2021

Description

Tails automatic upgrades were broken between versions 4.14 - 4.18 inclusive (Tails announcement), and some users on older versions of Tails may not realize that they are missing auto-updates, and that there is a manual step required to fix them.

We could:

  • Make no code changes, and continue to use support messaging channels etc to remind folks of this issue
  • Add text to the SecureDrop updater wizard, prompting users to update if their version of Tails is too old, or
  • Perform the steps to fix automatic Tails updates ourselves, which (according to the above link) consist of
torsocks curl --silent https://tails.boum.org/isrg-root-x1-cross-signed.pem \
| sudo tee --append /usr/local/etc/ssl/certs/tails.boum.org-CA.pem \
&& systemctl --user restart tails-upgrade-frontend

I'm kind of in favour of the last option, and I can put in a PR for a check at the end of securedrop_init right before our GUI updater runs. What do others think? [edit: filing now so we can discuss inclusion in 2.1.0]

@zenmonkeykstop
Copy link
Contributor

I'm more in favour of 2 (and also 1) than 3, just because altering the user's certs without their knowledge gives me the heebie-jeebies, but I'm not 100% against it.

@rocodes
Copy link
Contributor Author

rocodes commented Sep 20, 2021

Yeah, that's very fair. Ok, maybe we can talk about it tomorrow and see what people think. The downside of 2 is that we'd need to settle on some translation strings pretty quickly.

@zenmonkeykstop zenmonkeykstop added this to the 2.1.0 milestone Sep 21, 2021
@rocodes rocodes self-assigned this Sep 21, 2021
@rocodes
Copy link
Contributor Author

rocodes commented Sep 22, 2021

Per our discussion, here's an implementation of the third option. I've tested it on Tails 4.13 and 4.18. If this seems like roughly an approach we like, I'll submit a PR.

@rocodes
Copy link
Contributor Author

rocodes commented Sep 27, 2021

A little more digging, a little more stress.

My proposed method for validating the new cert was going to be to rely on the DST_ROOT_CA_X3.pem that cross-signs the new cert and is already installed on Tails workstations. However, the x3 cert is expiring in 3 days, so after the 30th, the verification will fail with error 10 at 1 depth lookup: certificate has expired.

The other way we could do any kind of verification on the cert is to also download it from the LetsEncrypt website, and only install it if the versions from the tails website and the LE website match.

Note: the Tails team does not include any kind of verification in their docs.

Feedback welcome!

@zenmonkeykstop
Copy link
Contributor

If we can't (or don't want to) ignore the expiry time with something like the -no_check_time flag, then the fallback option would just be to do the Tails version detection and throw up a dialog to users encouraging them to manually upgrade. Even just a system notification would be better than nothing IMO

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants