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

Start updater at boot, remove existing svs-disp backgound updater #415

Closed
emkll opened this issue Jan 22, 2020 · 3 comments · Fixed by #470
Closed

Start updater at boot, remove existing svs-disp backgound updater #415

emkll opened this issue Jan 22, 2020 · 3 comments · Fixed by #470

Comments

@emkll
Copy link
Contributor

emkll commented Jan 22, 2020

In #396, we have introduced a launcher to provide a way for users to control the update process. We would like the checks to happen as soon as the system boots to desktop.

We should re-use the autostart logic provided in [1] by replacing the background dispvm template update script (securedrop-login) by the QT application introduced in #396

[1] https://github.com/freedomofpress/securedrop-workstation/pull/355/files#diff-19fc9e35327834b65d0d380e0da1a89bR19

@eloquence
Copy link
Member

eloquence commented Jan 22, 2020

This could be split into three iterations:

  • first iteration: remove securedrop-login
  • second iteration: launch preflight updater upon login
  • third iteration: ensure that only one updater can be launched

@eloquence
Copy link
Member

Regarding launching the preflight updater upon login, I admit to being somewhat ambivalent. Having two dueling paths to launch the app (login & desktop icon) could be confusing, and having the client login window pop up in every session feels a bit constraining for future use cases that may be independent of the client app.

That said, since it's best to ensure that the workstation is up-to-date regardless of what the user does with it, I agree this is the way to go at this time. Adding the first two iterations to the sprint.

@eloquence eloquence added this to Current Sprint (1/22-2/5) in SecureDrop Team Board Jan 22, 2020
@eloquence
Copy link
Member

eloquence commented Feb 13, 2020

third iteration: ensure that only one updater can be launched

This was actually done in #445. We don't check whether the client itself is running, which could be a good follow-up. The client does have its own "only one at a time" check.

@eloquence eloquence mentioned this issue Feb 19, 2020
9 tasks
@emkll emkll moved this from Current Sprint (2/20-3/4) to In Development in SecureDrop Team Board Feb 27, 2020
SecureDrop Team Board automation moved this from In Development to Done Feb 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

2 participants