Closed eloquence closed 3 years ago
During the 10/15-10/28 sprint, we're aiming to land the remaining changes in #471 (and the reply badges release blocker https://github.com/freedomofpress/securedrop-client/issues/1149) and then begin the QA of all components. The actual release will likely happen in early November.
Started building out the combined non-template consolidation test plan in this issue; see changelog tracking doc for current status. Still a couple of client changes to cover, will add those tomorrow.
The test plan in this issue now fully reflects the selection and prioritization in the changelog tracking doc. What remains is:
As a reminder, the database migration in https://github.com/freedomofpress/securedrop-client/pull/1162 is a release blocker, and we should not kick off full pre-release QA until it lands.
Completed a happy-path upgrade on hardware.
0.2.1
work
, say):
https://github.com/freedomofpress/securedrop-workstation.git
repo and ensure that it is on the main
branchdom0
:
dom0
using qvm-run --pass-io work "tar -c -C /home/user securedrop-workstation" | tar xvf -
sudo bash ~/securedrop-workstation/utils/qa-switch.sh
sudo qubes-dom0-update -y
and verify that it is now the release candidate with dnf list securedrop-workstation-dom0-config
qvm-ls --tags sd-workstation
sudo bash ~/securedrop-workstation/utils/qa-switch.sh
rm ~/.securedrop_launcher/sdw-{last_updated,update-status}
tail -f ~/securedrop_launcher/logs/launcher.log
in dom0
dom0
, run `qvm-ls --tags sd-workstation, and verify that:
sd-(large|small)-buster-template)
and securedrop-workstation-buster
.sd-app
, sd-log
, sd-proxy
, and sd-gpg
are based on sd-small-buster-template
sd-devices-dvm
and sd-viewer
are based on sd-large-buster-template
dom0
command: time /opt/securedrop/launcher/sdw-launcher.py --skip-delta=0
and record the time here: 10m6ssdw-admin
securedrop-admin
to sdw-admin
rename (Issue: #586; PR: #596)securedrop-admin
can no longer be run in dom0
sdw-admin
in dom0
sdw-admin --validate
still functions as expecteddom0
, note the current font size of the "Default Font", then increase it to a very high value, e.g., 17./opt/securedrop/launcher/sdw-launcher.py --skip-delta 0
. Complete the updater process while observing the following:host
directory exists in ~/QubesIncomingLogs
on sd-log
(only relevant for "Fresh install" scenario, otherwise the directory will be present)
logger LOGME
in sd-app
, sd-whonix
, and sd-log
.~/QubesIncomingLogs/sd-app
and ~/QubesIncomingLogs/sd-whonix
sd-log
directory exists in ~/QubesIncomingLogs
on sd-log
.0.2.1
work
, say):
https://github.com/freedomofpress/securedrop-workstation.git
repo and ensure that it is on the main
branchdom0
:
dom0
using qvm-run --pass-io work "tar -c -C /home/user securedrop-workstation" | tar xvf -
sudo bash ~/securedrop-workstation/utils/qa-switch.sh
rm ~/.securedrop_launcher/sdw-{last_updated,update-status}
dom0
:
0.4.0.1-fc25
, with dnf list securedrop-workstation-dom0-config
qvm-ls --tags sd-workstation
tail -f ~/securedrop_launcher/logs/launcher.log
in dom0
(Reboot requested at this stage, which I performed.)
dom0
:
0.5.0.*-fc25
, with dnf list securedrop-workstation-dom0-config
qvm-ls --tags sd-workstation
I'm seeing only references to sd-small-buster-template
and sd-large-buster-template
, and the old templates no longer exist. Given the reboot, this is likely expected behavior.
sudo bash ~/securedrop-workstation/utils/qa-switch.sh
sdw-admin --apply
to apply the correct template configuration.
0.2.2
Double-clicking icon does nothing, getting an error: sd-app: command failed with code: 2
if running launcher via CLI. VM indicates update pending, so I'm rebooting the whole system. After reboot, we're good:
Except that the version is 0.2.1-dev-20201029-164632
because we're using a nightly build that overrides the 0.3.0
version configured in the securedrop-client
repo. I've updated that in the test plan.
dom0
, run qvm-ls --tags sd-workstation
, and verify that:
sd-(large|small)-buster-template)
and securedrop-workstation-buster
.And sd-devices-dvm
for sd-devices
.
sd-app
, sd-log
, sd-proxy
, and sd-gpg
are based on sd-small-buster-template
sd-devices
and sd-viewer
are based on sd-large-buster-template
sd-devices
is listed as using the template sd-devices-dvm
, and sd-devices-dvm
is listed as using the template sd-large-buster-template
.
Updater runtime:
real 8m38.093s
user 0m15.941s
sys 0m11.154s
sdw-admin
securedrop-admin
to sdw-admin
rename (Issue: #586; PR: #596)securedrop-admin
can no longer be run in dom0
sdw-admin
in dom0
sdw-admin --validate
still functions as expecteddom0
, note the current font size of the "Default Font", then increase it to a very high value, e.g., 17./opt/securedrop/launcher/sdw-launcher.py --skip-delta 0
. Complete the updater process while observing the following:sd-gpg
, temporarily move ~/.gnupg
to ~/.gnupg.bak
to cause decryption errorssd-gpg
, move ~/.gnupg.bak
back to ~/.gnupg
host
directory exists in ~/QubesIncomingLogs
on sd-log
(only relevant for "Fresh install" scenario, otherwise the directory will be present)logger LOGME
in sd-app
, sd-whonix
, and sd-log
.~/QubesIncomingLogs/sd-app
and ~/QubesIncomingLogs/sd-whonix
sd-log
directory exists in ~/QubesIncomingLogs
on sd-log
.(In spite of the :x:s, all good news so far; as far as I can tell the sd-devices-dvm
output is just an artifact of how that particular VM works, given the persistent-name disposable VM approach.)
work
, say):
securedrop-workstation-dom0-config
version (sdw-latest.rpm
, say) from https://yum-test.securedrop.org/workstation/dom0/f25/
https://github.com/freedomofpress/securedrop-workstation.git
repo and ensure that it is on the main
branchdom0
:
dom0
using qvm-run --pass-io work "cat sdw-latest.rpm" > sdw-latest.rpm
dom0
using qvm-run --pass-io work "tar -c -C /home/user securedrop-workstation" | tar xvf -
sudo dnf install sdw-latest.rpm
sudo bash ~/securedrop-workstation/utils/qa-switch.sh
sdw-admin --apply
dom0
, run qvm-ls --tags sd-workstation
, and verify that:
sd-(large|small)-buster-template)
and securedrop-workstation-buster
.sd-app
, sd-log
, sd-proxy
, and sd-gpg
are based on sd-small-buster-template
sd-devices
and sd-viewer
are based on sd-large-buster-template
sdw-admin
securedrop-admin
to sdw-admin
rename (Issue: #586; PR: #596)securedrop-admin
can no longer be run in dom0
sdw-admin
in dom0
sdw-admin --validate
still functions as expecteddom0
, note the current font size of the "Default Font", then increase it to a very high value, e.g., 17./opt/securedrop/launcher/sdw-launcher.py --skip-delta 0
. Complete the updater process while observing the following:sd-gpg
, temporarily move ~/.gnupg
to ~/.gnupg.bak
to cause decryption errorssd-gpg
, move ~/.gnupg.bak
back to ~/.gnupg
host
directory exists in ~/QubesIncomingLogs
on sd-log
(only relevant for "Fresh install" scenario, otherwise the directory will be present)logger LOGME
in sd-app
, sd-whonix
, and sd-log
.~/QubesIncomingLogs/sd-app
and ~/QubesIncomingLogs/sd-whonix
sd-log
directory exists in ~/QubesIncomingLogs
on sd-log
.NOTES: The first time I tried this, I ran into this error (which I thought we had fixed): https://github.com/freedomofpress/securedrop-export/issues/51. I will need to figure out what the STR is but basically I plugged in the printer and connected the cable to my Qubes laptop, clicked on "print" next to an attached document in the client, and sd-devices
started for the first time, then I saw the error reported in this issue: https://github.com/freedomofpress/securedrop-export/issues/51. To fix this I closed the client and unplugged the printer cable from the Qubes laptop and plugged it in again with a new cable, confirmed that it auto-attached to sd-devices
properly, started the client, and printed successfully.
sd-devices
VM is startedsd-devices
VM, and clicks Continue:
0.2.1
work
, say):
https://github.com/freedomofpress/securedrop-workstation.git
repo and ensure that it is on the main
branchdom0
:
dom0
using qvm-run --pass-io work "tar -c -C /home/user securedrop-workstation" | tar xvf -
sudo bash ~/securedrop-workstation/utils/qa-switch.sh
rm ~/.securedrop_launcher/sdw-{last_updated,update-status}
dom0
:
0.4.0.1-fc25
, with dnf list securedrop-workstation-dom0-config
qvm-ls --tags sd-workstation
tail -f ~/securedrop_launcher/logs/launcher.log
in dom0
dom0
:
0.5.0.*-fc25
, with dnf list securedrop-workstation-dom0-config
sudo bash ~/securedrop-workstation/utils/qa-switch.sh
sdw-admin --apply
to apply the correct template configuration.0.2.1-dev-20201029-164632
sd-app
was running, since the GUI updater ran on the previous boot, so the launcher logic tried to start the app (and failed, since the template was not properly configured).dom0
, run qvm-ls --tags sd-workstation
, and verify that:
sd-(large|small)-buster-template)
and securedrop-workstation-buster
.sd-app
, sd-log
, sd-proxy
, and sd-gpg
are based on sd-small-buster-template
sd-devices-dvm
and sd-viewer
are based on sd-large-buster-template
dom0
command: time /opt/securedrop/launcher/sdw-launcher.py --skip-delta=0
and record the time here: * 7m5sFocused on exploratory MIME type testing to start with, since this is one of the highest risk areas that was modified in the consolidation.
sd-app
and sd-viewer
; xdg-open
and nautilus
behave as expected for each.I am noticing that Nautilus offers ImageMagick as an option for images on sd-app
, not sure if that was the case before, but may be worth removing from the small
template if it's not needed? Note that ImageMagick has its own graphical viewer app.
after valid login:
when a source is selected in source list:
when the upper right 3-dot button is clicked:
when a source is starred in source list, and the client is closed and reopened in Online mode:
when a source is selected in the source list:
I am noticing that Nautilus offers ImageMagick as an option for images on sd-app
Checking on a 0.4.0 prod machine right now, I don't see ImageMagick as an option in the Nautilus right-click pane. I do see the package imagemagick
marked as automatically installed in sd-app-buster-template
, however, so the inclusion of the package isn't new. Frankly I'd prefer to remove nautilus, since we started including it before we had the client interface to handle submissions.
I don't see ImageMagick as an option in the Nautilus right-click pane
Correction: if I right-click on an image file in sd-app
on 0.4.0 prod, I see "Open With Open in Disposable VM" [sic] as the first and default option. If I choose "Open With Other Application," though, then the "Selection Application" dialog does indeed suggest ImageMagick. So definitely not a regression as part of 0.5.0. I don't propose we remove imagemagick from the small template right now, because it's automatically being installed—although I would like to trace what's including it.
sd-devices
VM is startedsd-export-<timestamp>/export_data
(skipped repopulating the client)
Still working thru the rest of the test plan, but on a fresh install the logging scenario is failing for me - specifically, logs are only showing up for sd-whonix and securedrop-workstation-buster.
Completed a happy-path upgrade on hardware.
0.2.1
work
, say):
https://github.com/freedomofpress/securedrop-workstation.git
repo and ensure that it is on the main
branchdom0
:
dom0
using qvm-run --pass-io work "tar -c -C /home/user securedrop-workstation" | tar xvf -
sudo bash ~/securedrop-workstation/utils/qa-switch.sh
sudo qubes-dom0-update -y
and verify that it is now the release candidate with dnf list securedrop-workstation-dom0-config
qvm-ls --tags sd-workstation
sudo bash ~/securedrop-workstation/utils/qa-switch.sh
rm ~/.securedrop_launcher/sdw-{last_updated,update-status}
tail -f ~/securedrop_launcher/logs/launcher.log
in dom0
dom0
, run `qvm-ls --tags sd-workstation, and verify that:
sd-(large|small)-buster-template)
and securedrop-workstation-buster
.sd-app
, sd-log
, sd-proxy
, and sd-gpg
are based on sd-small-buster-template
sd-devices-dvm
and sd-viewer
are based on sd-large-buster-template
dom0
command: time /opt/securedrop/launcher/sdw-launcher.py --skip-delta=0
and record the time here: 9m54ssdw-admin
securedrop-admin
to sdw-admin
rename (Issue: #586; PR: #596)securedrop-admin
can no longer be run in dom0
sdw-admin
in dom0
sdw-admin --validate
still functions as expectedhost
directory exists in ~/QubesIncomingLogs
on sd-log
(only relevant for "Fresh install" scenario, otherwise the directory will be present)logger LOGME
in sd-app
, sd-whonix
, and sd-log
.~/QubesIncomingLogs/sd-app
and ~/QubesIncomingLogs/sd-whonix
sd-log
directory exists in ~/QubesIncomingLogs
on sd-log
.On a separate note for the client, can anyone please upload a markdown file (*.md) file as a source and try to view it as a client?
Performed a fresh install on rc3. Did not a few test failures, but they went away after an updater run and a reboot, see comment in https://github.com/freedomofpress/securedrop-workstation/issues/634#issuecomment-722025707
dom0
, run qvm-ls --tags sd-workstation
, and verify that:
sd-(large|small)-buster-template)
and securedrop-workstation-buster
.sd-app
, sd-log
, sd-proxy
, and sd-gpg
are based on sd-small-buster-template
sd-devices-dvm
and sd-viewer
are based on sd-large-buster-template
sdw-admin
securedrop-admin
to sdw-admin
rename (Issue: #586; PR: #596)securedrop-admin
can no longer be run in dom0
sdw-admin
in dom0
sdw-admin --validate
still functions as expectedhost
directory exists in ~/QubesIncomingLogs
on sd-log
(only relevant for "Fresh install" scenario, otherwise the directory will be present)logger LOGME
in sd-app
, sd-whonix
, and sd-log
.~/QubesIncomingLogs/sd-app
and ~/QubesIncomingLogs/sd-whonix
sd-log
directory exists in ~/QubesIncomingLogs
on sd-log
.Since @conorsch already tested logging for the rc3 fresh install path on the same hardware that I have, I started to perform the sad path upgrade but ran into a setup issue (forgot to run sdw-admin --uninstall
and then later make clean
before installing 0.4.0 again) so the sad path scenario didn't go smoothly for me -- it was too happy of a path. Conor and I discussed how the rc3 fix has been thoroughly tested at this point so it makes the most sense to just set my workstation up with a fresh 0.4.0 prod install to prepare for testing the release as soon as it goes live tomorrow. I can even follow the same admin instructions we provide with the release.
Happy path failed for me - updater stalled indefinitely at 35%. Killed updater and reran it, it completed "successfully", updating all templateVMs but did not re-run sdw-admin --apply
. This broke the logging setup (possibly what @emkll was seeing earlier?).
Ran sdw-admin --apply
in dom0 , which corrected logging issues.
dom0
, run qvm-ls --tags sd-workstation
, and verify that:
sd-(large|small)-buster-template)
and securedrop-workstation-buster
.sd-app
, sd-log
, sd-proxy
, and sd-gpg
are based on sd-small-buster-template
sd-devices-dvm
and sd-viewer
are based on sd-large-buster-template
sdw-admin
securedrop-admin
to sdw-admin
rename (Issue: #586; PR: #596)securedrop-admin
can no longer be run in dom0
sdw-admin
in dom0
sdw-admin --validate
still functions as expectedhost
directory exists in ~/QubesIncomingLogs
on sd-log
(only relevant for "Fresh install" scenario, otherwise the directory will be present)logger LOGME
in sd-app
, sd-whonix
, and sd-log
.~/QubesIncomingLogs/sd-app
and ~/QubesIncomingLogs/sd-whonix
. Opened https://github.com/freedomofpress/securedrop-workstation/issues/637 to track an issue where some config files remain on sd-whonix's template after uninstallsd-log
directory exists in ~/QubesIncomingLogs
on sd-log
.
:exclamation: I did notice however that due to changes intoduced in https://github.com/freedomofpress/securedrop-log/pull/18, there are side effects to how dispvm logs are being managed: In the case of viewer VMs, they are assigned a random name. This means that for each VM started, it will create a new folder everytime. If I recall correctly, in the path, the DispVMs hostname would be that of its DispVM Template and would append DispVM logs to the same file/folder for all viewer DispVMs
sd-rsyslog binary is working correctly and forwarding the files correctly, it seems to be the rsyslog configuration on the whonix vmPrinting on brother DCP 7065DN
was smooth from client.
Tested the changes introduced in https://github.com/freedomofpress/securedrop-client/pull/1184 using a production 0.2.1 client and database, reporting a successful migration of the draftreplies
table to include correct journalist associations. I will push a new 0.3.0 tag to build production debs based on that revision
SecureDrop Workstation was released on 2020-11-09, closing
Release date: November 4, 2020
This is a tracking issue for preparing the next release of the SecureDrop Workstation, which will ship consolidated templates via the preflight updater (#471), as well as other unreleased changes from
main
.In addition to an RPM update, we will simultaneously issue new releases of most SecureDrop Workstation components, including the SecureDrop Client. These have their own versioning, but for simplicity, this issue uses "0.5.0" as a shorthand for the cross-component release.
This release will include also include release to other workstation components:
Release steps
Prepare
[x] Push signed tags for applications (client/proxy/log/export)
[x] Packaging changes including debian changelog for all packages https://github.com/freedomofpress/securedrop-debian-packaging/pull/207
[x] Merge packaging changes and pushed signed tag to securedrop-debian-packaging https://github.com/freedomofpress/securedrop-debian-packaging/releases/tag/0.2.13
[x] Build production debs
[x] Open PR to securedrop-debian-packages LFS repo, sign release file and open PR: https://github.com/freedomofpress/securedrop-debian-packages-lfs/pull/37
[x] Open PR containing final release commit for securedrop-workstation
[x] Merge and sign tag for workstation repo
[x] Build and sign securedrop-workstation-dom0-config rpm
[x] Open PR to securedrop-workstation-prod-rpm-packages LFS repo : https://github.com/freedomofpress/securedrop-workstation-prod-rpm-packages-lfs/pull/12
Release
[x] Merge debian packages into
main
[x] Merge RPMs into
main
[x] Update docs
Test plan
Please see the 0.5.0 test plan on the wiki.