-
Notifications
You must be signed in to change notification settings - Fork 47
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
Switch to 2021 signing key; update tests #700
Conversation
Tested this by switching my environment to
|
I've added a test plan and per discussion with @conorsch and @creviera added a commit to force a full migration run via a flag dropped in postinst, to ensure that the key is provisioned to If it looks good so far, we discussed that as a next step, we can add a temporary commit to use the new signing key for |
Unfortunately I'm stuck on step 1 of the test plan due to an issue with |
|
❌ Observe that the fingerprints for all three keys are identical, confirming that the new key was successfully provisioned.
|
@creviera Can you confirm that the |
it's set to and later i will uninstall fedora-33 and switch back to fedora-32 to do a little troubleshooting around the early issue with being unable to find the fedora-33 template |
after running this a second time, i see the correct release key in dom0 but sys-firewall is still showing the test key :/ config.json is set to UpdateJust spoke to @eloquence about this and learned that the Updater will skip copying the key over to |
@eloquence now that the updater can access https://deb.qubes-os.org/, it has run successfully, but i'm still unable to successfully complete your test plan because |
The "full state run" logic that kicks in to ensure that |
@conorsch |
When I switched from using the Also worth noting that I do not use the standard |
|
Once |
My system managed to find fedora-33 template, but at first attempt it failed because of a faulty mirror. |
83ad8b5
to
583b647
Compare
Looks like signing an rpm with the key works great, see freedomofpress/securedrop-yum-test#24 (comment). Next step is to undo the temporary commits and I think we can close freedomofpress/securedrop-yum-test#24 without merging since it was created for testing purposes. @conorsch does that sound good to you? |
If we wanted to test a prod-like updater run, we could publish the RC1 RPM to yum-test by merging freedomofpress/securedrop-yum-test#24. Note however that this PR's branch has already been modified to drop your temporary commit and to bump the version, so we would either need to use an older version of the branch, or restore it to the previous state, so that the updater registers the RPM on |
583b647
to
d4a8d1b
Compare
I provisioned a staging environment with the prod key and ran the updater, which successfully updated me to the 0.5.4-0 RC1 signed with the prod key. Updater ran without errors.
I'll shift gears to a SecureDrop Ansible issue for the rest of today, but tomorrow I can take a look at the dual key logic with @conorsch. |
Spent some more time with these changes today. In short, they work well, and I'm comfortable with proceeding to final release for 0.5.4. Ideally we'd have support for multiple gpg keys, same as we do for apt (vs yum/dnf) in e.g. freedomofpress/securedrop-builder#250, but that deserves its own issue. I'm going to open a PR to revert the yum-test changes in freedomofpress/securedrop-yum-test#24, and drop the temporary commits here. Then we can proceed with final review. Since these changes are the last we intend to include for 0.5.4, I'm able to bump the final version in this PR and tag. Also fine to do that in a separate PR post-merge. |
We've performed the manual testing as part of [0], so let's remove the non-standard signature and overwrite it with a sig from the standard test key, i.e. 4ED79CC3362D7D12837046024A3BE4A92211B03C. [0] freedomofpress/securedrop-workstation#700
1419801
to
d4a8d1b
Compare
Dropped the temporary commit and declaring this ready. The temporary commit was:
|
once merged i'll open a pr with the version bump and changelog updates so @conorsch can prod-sign the tag and review |
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.
Approving based on copious testing. We'll proceed with version bump and tagging in a subsequent PR, towards #699.
Switch to 2021 signing key; update tests
Status
Ready for final review
Description of Changes
Fixes #697. Preserves the old key, but only provisions the new one for verification purposes.
Does not remove the legacy key from the RPM database of existing systems; it will simply be let to expire.
Test plan
Estimated testing time: 1-2 hours (significant wall time due to full state run and regular updater run)
make clone
this branch intodom0
andsudo dnf reinstall
(ormake staging
if you don't have a previously provisioned environment) the freshly built RPM fromrpm-build/RPMS/noarch
.prod
state -- ensure that the environment in both/usr/share/securedrop-workstation-dom0-config/config.json
and/srv/salt/sd/config.json
is set toprod
dom0
, run/opt/securedrop/launcher/sdw-launcher.py --skip-delta 0
. This will force an updater run. Because a full migration will run, this is expected to take a long time -- longer still if you have not yet installed fedora-33.~/.securedrop_launcher/logs/launcher.log
and~/.securedrop_launcher/logs/launcher-detail.log
for errors. You may see errors "An Exception occurred while executing state.highstate" inlauncher-detail.log
. This is due to Salt highstate generation doesn’t work on Fedora templates QubesOS/qubes-issues#6580 and expected to be resolved later this week.dom0
, assuming your code checkout is in/home/user/securedrop-workstation/
rungpg --with-fingerprint --with-colons ~/securedrop-workstation/sd-workstation/securedrop-release-signing-pubkey-2021.asc
.dom0
, rungpg --with-fingerprint --with-colons /etc/pki/rpm-gpg/RPM-GPG-KEY-securedrop-workstation
sys-firewall
, rungpg --with-fingerprint --with-colons /etc/pki/rpm-gpg/RPM-GPG-KEY-securedrop-workstation
/opt/securedrop/launcher/sdw-launcher.py --skip-delta 0
.launcher.log
during this run. This shows that we're only running the full migration once.