-
Notifications
You must be signed in to change notification settings - Fork 46
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
Enforce updates on login via dom0 launcher app #396
Conversation
2e3d863
to
ab0ce6f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is awesome work, I've provisioned and tried this out, works great, a few questions/thoughts inline
note to other people trying this that right now the strings listed in #341 (comment) aren't used - this PR thus far is just a demo of the basic functionality, we can update the text shown to the user (and probably hide the window that has the full details of what is happening) once we agree on the basic functionality/technical approach |
ce3b8a2
to
5e8bba3
Compare
5e8bba3
to
3b42bd4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(posting some notes made from synchronous PR review)
a34c8ce
to
5cf777c
Compare
(Regarding the icon, I noticed that it's possible to adjust the Qubes icon settings to a higher size, which also means more text for the label. It's set to 64 pixels in the above screenshot. If it's possible to change that preference during provisioning, that may be a nice follow-up tweak.) |
I'm noticing that every time I run the launcher, the VMs get the green "restart required" indicator in the Qube manager widget (see top right in the screenshot below), even if no updates were available. To verify this behavior, I did restart the |
c484c5d
to
7a2561d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looking really good. @kushaldas or others if you have comments or suggestions on the overall approach and code structure here please chime in as I think this will be ready for official review soon
launcher/sdw_updater_gui/Updater.py
Outdated
sdlog.error(str(e)) | ||
updates_required = True | ||
finally: | ||
try: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit/optional: candidate for factoring out into separate function (code in the finally block is used in 2 places), would make testing a bit easier for these functions, but also fine to leave since it's only used in two places (if we end up adding a third we can factor out at that time)
6674cf4
to
9e8d1ff
Compare
Will now shut down all VMs, and then boot all VMs to pick up updates.
This reduces the amount of callbacks and threads required, and simply update the progressBar from {Update,Upgrade}Threads by emitting a signal to update_progress_bar slot
This is required because Qubes will autostart VMs, and this guards against failure of `qvm-start` in those scenarios.
- improve generator usage - improve file handling - remove variables that are no longer use - correct comment
…ndow and prevent resizing
Use <hn> tags in lieu of standalone label tags, with rich text markup
- Upgrade dict returned by the app is now properly populated with results - svs flag is now in /home/user/.securedrop.client/
- Add Cancel button - Add Horizontal Spacer to button row to alight buttons to the right - Fix failed update scenario - Fix vertical margins/alignment
- sd-svs -> sd-app - sd-export -> sd-devices - sd-svs-disp -> sd-viewer
607ed78
to
91efa24
Compare
If a user were to close/exit the launcher and re-run it, they would be able to circumvent the required reboot. To ensure reboots were applied, we will now track the timestamp for the dom0 update status flag, and compare with the current system boot time. If the boot time is before the reboot flag, the launcher will ask the user to reboot, else it will apply whatever status is required.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've confirmed all of my comments have been addressed, thanks for your patience on this @emkll
I performed a full functional test of this in Qubes after reprovisioning on latest master
(after the VM name changes):
-
make prep-dom0
succeeds without error - clicking on Desktop icon spawns the launcher
- Logs for the updater appear in
~/.securedrop-launcher/logs/launcher.log
Scenario 1: All VMs up to date:
- The launcher simply runs, checks for updates, no updates are required, the client can be launched.
- sd-svs flags are in place (
/home/user/.securedrop.client/{sdw-last-updated,sdw-update-flag}
are correct - dom0 flags (
~/.securedrop-launcher/{sdw-last-updated,sdw-update-flag}
are correct
Scenario 2: Reboot required
- The launcher indicates update is required
- Updates are applied
- The launcher recommends a user reboot
- sd-svs flags are in place (
/home/user/.securedrop.client/{sdw-last-updated,sdw-update-flag}
are correct - dom0 flags (
~/.securedrop-launcher/{sdw-last-updated,sdw-update-flag}
are correct - after reboot, Scenario 1 completes without error
Scenario 3: Updates required but no reboot required
- The launcher indicates update is required
- Updates are applied
- The launcher recommends you start the client
- sd-svs flags are in place (
/home/user/.securedrop.client/{sdw-last-updated,sdw-update-flag}
are correct - dom0 flags (
~/.securedrop-launcher/{sdw-last-updated,sdw-update-flag}
are correct - The client starts on the latest version.
one other followup we can file is adding the reboot tasks to the progress bar (such that it's not stalled at 100% during the reboot cycle)
I'm going to hold off on formally approving until a second person can review (and ideally test) since given the criticality of this feature it would be good to have another set of eyes. If no one is available given our other wip, I will merge regardless in a couple of days.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@conorsch mentioned in chat he's reviewing this so since we might get a second set of eyes before EOD I will approve so that my review is not blocking. Confirming once more for the comment skimmer that all my comments are addressed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes are solid. Performed a visual review of the diff, and have no requests on top of what's already been discussed (and implemented). In terms of functional review, have completed scenarios 1 & 3, with no major snags. The follow-ups identified in the OP are indeed worth tracking in separate tickets (e.g. #411).
Mighty fine work here, @emkll.
In order to unblock merge, I'm dismissing @kushaldas's prior review. Have confirmed that the changes requested were indeed addressed. Great attention to detail in that review—thanks, @kushaldas! |
All changes have been addressed! \m/
closes #341, closes freedomofpress/securedrop-updater#34
The goal is to enforce critical VM (incl dom0) updates on client login. For now, the interface is launched via the .desktop shortcut, but we also have this run on startup (similar to how updates are handled in #355)
Test Plan
make prep-dom0
succeeds without errorScenario 1: All VMs up to date:
/home/user/.securedrop.client/{sdw-last-updated,sdw-update-flag}
are correct~/.securedrop-launcher/{sdw-last-updated,sdw-update-flag}
are correctScenario 2: Reboot required
sudo dnf downgrade zlib && sudo poweroff
)/home/user/.securedrop.client/{sdw-last-updated,sdw-update-flag}
are correct~/.securedrop-launcher/{sdw-last-updated,sdw-update-flag}
are correctScenario 3: Updates required but no reboot required
sudo apt install securedrop-client=<version>
and shutdown the template/home/user/.securedrop.client/{sdw-last-updated,sdw-update-flag}
are correct~/.securedrop-launcher/{sdw-last-updated,sdw-update-flag}
are correctFollow-ups
Improve the UI theme/styling, (e.g., add SecureDrop logo)Tweak updater icon, label #413Parallelize updates (2x concurrency)Perform update checks concurrently #403Start the Launcher on boot, similar to Updates sd-svs-disp-template on XFCE login #355415Use dom0 date flag to skip checks if check was done less than 8h agoSkip VM updates if last check was performed <X hours ago #402remove dailyRemove update cron job #412securedrop-update-cron
once 4. is completed (per [WIP] Add security update notification script #389 (comment))Only reboot AppVMs that need rebooting (AppVMs whose TemplateVM was updated as part of this run, see Enforce updates on login via dom0 launcher app #396 (comment))After applying updates, only reboot VMs that need updating securedrop-updater#38