Release securedrop-workstation-dom0-config 0.11.0

[zenmonkeykstop]

• RM: @zenmonkeykstop
• Deputy RM: TK
• Comms: TK
• QA: TK

This release targets Qubes 4.1 and increments the fedora version from -38 to -39, mirroring previous bumps almost identically. It is numbered as 0.11.0 for consistency, but is treated as a hotfix release in that it is based on release/0.10.0, not main, as main is now 4.2-only.

For initial QA, the 0.11.0 rpm can be built locally from the release/0.11.0 branch and applied via dnf as described in the test plan. For preflight testing, it should be installed via yum-qa.securedrop.org.

Release process:

Release:

• [x] [In release branch] Bump version via update_version script, and update changelog in rpm .spec file
• [x] [In release branch] Create prod tag (signed by release signing key)
• [x] Build prod artifact, sign with release key, commit build logs
• [x] QA/smoketest of prod artifact (stuff rpm in dom0 of SDW prod machine)
• [x] Publish prod artifact to yum repo

Post-release

• [ ] freedomofpress/securedrop-dev-docs#113
• [ ] Retro if/as needed
• [ ] Update documentation: https://github.com/freedomofpress/securedrop-workstation-docs/issues/200

QA Test Plan

Fresh install (prodlike install)

Qubes 4.1.2 expected, please note hardware

Prep:

Testing:

• [x] RPM installs successfully in dom0
• [x] with config in place, sdw-admin --apply completes successfully
• [x] fedora-39 wis installed as part of --apply run
• [x] sys-* AppVMs use fedora-39 versions of their expected templates
• [x] basic client functionality requiring network access (login, first sync) completed successfully.
• [x] basic client functionality requiring USB support (export, print) completed successfully

Upgrade from 0.10.0 (no fedora-39 templates preinstalled)

Qubes 4.1.2 expected, please note hardware

Testing:

• [ ] RPM installs succesfully via sudo dnf install <name> in dom0, replacing the existing 0.10.0 rpm
• [ ] with config in place, sdw-admin --apply completes successfully
• [ ] fedora-39 wis installed as part of --apply run
• [ ] sys-* AppVMs use fedora-39 versions of their expected templates
• [ ] basic client functionality requiring network access (login, first sync) completed successfully.
• [ ] basic client functionality requiring USB support (export, print) completed successfully

[@cfm] Upgrade from 0.10.0 (with fedora-39 templates preinstalled)

Qubes 4.1.2 expected, please note hardware

Testing:

• [ ] RPM installs succesfully via sudo dnf install <name> in dom0, replacing the existing 0.10.0 rpm
• [ ] with config in place, sdw-admin --apply completes successfully
• [ ] fedora-39 wis installed as part of --apply run
• [ ] sys-* AppVMs use fedora-39 versions of their expected templates
• [ ] basic client functionality requiring network access (login, first sync) completed successfully.
• [ ] basic client functionality requiring USB support (export, print) completed successfully

[cfm]

Edit: This was really for #1000.

Upgrade from 0.10.0 (no fedora-39 templates preinstalled)

Qubes 4.1.2 expected, please note hardware: ThinkPad X1 Carbon, 10th-generation

• [x] RPM installs succesfully via sudo dnf install <name> in dom0, replacing the existing 0.10.0 rpm
• [ ] with config in place, sdw-admin --apply completes successfully

No; sys-usb fails boot on fedora-39 in HVM mode, which is still our default on Qubes 4.1. This looks like QubesOS/qubes-issues#6029:

[2024-04-25 16:09:35] (XEN) MMIO emulation failed (1): d35v0 32bit @ 0008:3f000000 -> 
[2024-04-25 16:09:35] (XEN) d35v0 Triple fault - invoking HVM shutdown action 1
[2024-04-25 16:09:35] (XEN) *** Dumping Dom35 vcpu#0 state: ***
[2024-04-25 16:09:35] (XEN) ----[ Xen-4.14.6  x86_64  debug=n   Tainted: M     ]----
[2024-04-25 16:09:35] (XEN) CPU:    14
[2024-04-25 16:09:35] (XEN) RIP:    0008:[<000000003f000000>]
[2024-04-25 16:09:35] (XEN) RFLAGS: 0000000000010002   CONTEXT: hvm guest (d35v0)
[2024-04-25 16:09:35] (XEN) rax: 0000000000000000   rbx: 0000000040000000   rcx: 0000000000006fe8
[2024-04-25 16:09:35] (XEN) rdx: 0000000000006fe4   rsi: 0000000000000000   rdi: 0000000000000000
[2024-04-25 16:09:35] (XEN) rbp: 0000000000000000   rsp: 0000000000006fdc   r8:  0000000000000000
[2024-04-25 16:09:35] (XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
[2024-04-25 16:09:35] (XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
[2024-04-25 16:09:35] (XEN) r15: 0000000000000000   cr0: 0000000000000011   cr4: 0000000000000000
[2024-04-25 16:09:35] (XEN) cr3: 0000000000000000   cr2: 0000000000000000
[2024-04-25 16:09:35] (XEN) fsb: 0000000000000000   gsb: 0000000000000000   gss: 0000000000000000
[2024-04-25 16:09:35] (XEN) ds: 0010   es: 0010   fs: 0010   gs: 0010   ss: 0010   cs: 0008

sys-usb works in PV mode, with which sdw-admin --apply succeeds.

• [x] fedora-39 is installed as part of --apply run
• [x] sys-* AppVMs use fedora-39 versions of their expected templates
• [x] basic client functionality requiring network access (login, first sync) completed successfully.
• [x] basic client functionality requiring USB support (export, print) completed successfully

[zenmonkeykstop]

Checked to be sure - can't repro on a 6th-gen X1 Carbon. sys-usb is using sd-fedora-39-dvm and is booting and functional.

[cfm]

I've finished my testing in https://github.com/freedomofpress/securedrop-workstation/issues/999#issuecomment-2078117446 and narrowed it down to sys-usb in HVM mode (which doesn't work) versus PV mode (which does). Everything else works as expected.

If we don't see this again in further testing, then either:

1. I should prepare and run another upgrade scenario from v0.10 (quite time-expensive if I'm going to reset my main machine); or
2. we should accept this change of mode as the workaround we'll recommend if anyone encounters it in production.

[zenmonkeykstop]

Does the fedora-39 template in general fail for you in HVM mode? Like, rather than using our sd-fedora-39-dvm template, if you use fedora-39-dvm. If so, it might be worth flagging upstream.

[cfm]

In my latest testing sys-usb boots fine in HVM mode from both fedora-39-dvm and sd-fedora-39-dvm. I can't account for the initial failure without retesting on a fresh installation of Qubes 4.1. Let me know if you think that's worthwhile.

[zenmonkeykstop]

Preflight test:

• scenario: fresh install.
• hardware: 6th-gen X1 Carbon
• Qubes version: 4.1.2

Prep:

• installed RPM as per https://workstation.securedrop.org docs
• before running sdw-admin --apply, updated dom0_yum_repo_url value to https://yum-qa.securedrop.org/workstation/dom0` in dom0:/srv/salt/sd-default-config.yml

Testing:

• [x] RPM installs successfully in dom0
• [x] with config in place, sdw-admin --apply completes successfully
• [x] fedora-39 wis installed as part of --apply run
• [x] sys-* AppVMs use fedora-39 versions of their expected templates
• [x] basic client functionality requiring network access (login, first sync) completed successfully.
• [x] basic client functionality requiring USB support (export, print) completed successfully print not tested

[cfm]

Upgrade from v0.10.0 (with fedora-39 templates preinstalled)

Qubes 4.1.2 expected, please note hardware: ThinkPad T14

• [x] RPM installs succesfully via sudo dnf install <name> in dom0, replacing the existing 0.10.0 rpm
• [x] with config in place, sdw-admin --apply completes successfully
• ~~fedora-39 is installed as part of --apply run~~
• [x] sys-* AppVMs use fedora-39 versions of their expected templates
• [x] basic client functionality requiring network access (login, first sync) completed successfully.
• [x] basic client functionality requiring USB support (export, print) completed successfully

[legoktm]

This was released in https://github.com/freedomofpress/securedrop-yum-prod/pull/52 - see also https://securedrop.org/news/securedrop_workstation_0_11_0_released/