You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
dom0 updates recently started failing for longstanding SDW installs, with the behaviour that the SDW updater and GUI updater would fail, and on inspection of the updatevm console, the following message appeared:
1. Certificiate [sic] 188EDD3B7B22E6A3 invalid: certificate is not alive
because: The primary key is not live
because: Expired on 2023-07-04T10:52:20Z
2. Key 188EDD3B7B22E6A3 invalid: key is not alive
because: The primary key is not live
because: Expired on 2023-07-04T10:52:20Z
[...]
Error: GPG check FAILED
This is caused by this issue in RPM, where a key different subkeys but the same master key fingerprint (our use case) is not replaced in the rpm database when rpm --import is run. When we bumped our release key last summer, the updated key was put in place at /etc/pki/rpm-gpg/RPM-GPG-KEY-securedrop-workstation, but the rpm import command meant it wasn't imported into the rpm pubkey database. (Visible by querying pubkeys via rpm -qi and comparing).
Why now?
Hard to say why this didn't bite us sooner, but my best guess is that this upstream commit changed the behaviour of which rpm db material was 'winning' and being used in the updatevm. It came a few weeks after our key bump, so this would be the first time we would have released a new dom0 rpm since then.
Manual resolution
The good news is, the appropriate key is already on users' machines in dom0, in /etc/pki/rpm-gpg.
Provisioning update: We'll want to manage the key in the rpm database rather than assuming rpm --import will handle it for us, write tests against the pubkey in the rpm database (/var/lib/rpm on dom0) as well as the key in /etc/pki/rpm-gpg/. We can use this ticket to discuss what steps we want to take on the provisioning side.
Commenting that in the upstream ticket above, there's been some progress towards resolving this issue, so the combination of that plus our longer release key expiry (#1046) means hopefully we won't encounter this again in SDW, although we should keep it open until we're sure.
Don't want to close this til it's fully resolved upstream, but the current status is: fixed in 4.1 (workaround); not relevant for our release signing key for 3 more years in 4.2 (longer signing key expiry).
Summary
dom0 updates recently started failing for longstanding SDW installs, with the behaviour that the SDW updater and GUI updater would fail, and on inspection of the updatevm console, the following message appeared:
This is caused by this issue in RPM, where a key different subkeys but the same master key fingerprint (our use case) is not replaced in the rpm database when
rpm --import
is run. When we bumped our release key last summer, the updated key was put in place at/etc/pki/rpm-gpg/RPM-GPG-KEY-securedrop-workstation
, but the rpm import command meant it wasn't imported into the rpm pubkey database. (Visible by querying pubkeys viarpm -qi
and comparing).Why now?
Hard to say why this didn't bite us sooner, but my best guess is that this upstream commit changed the behaviour of which rpm db material was 'winning' and being used in the updatevm. It came a few weeks after our key bump, so this would be the first time we would have released a new dom0 rpm since then.
Manual resolution
The good news is, the appropriate key is already on users' machines in dom0, in
/etc/pki/rpm-gpg
.Next steps
rpm --import
will handle it for us, write tests against the pubkey in the rpm database (/var/lib/rpm
on dom0) as well as the key in/etc/pki/rpm-gpg/
. We can use this ticket to discuss what steps we want to take on the provisioning side.The text was updated successfully, but these errors were encountered: