Inplace-ugprade: enabling users to work around whonix EXPKEYSIG error

[deeplow]

A key expiration issue is currently effectively preventing updating Whonix qubes in Qubes 4.2 and it requires manual intervention in order to be fixed. This is a problem in itself that is probably affecting a significant number of users who have not yet migrated to 4.3. But the problem is exacerbated because the Qubes inplace upgrade too cannot finish "STAGE 1" if a qube fails to update.

This results in a potential problem for users: the current in-place upgrade instructions will fail on default installations and the users will never be able to pass STAGE 1. One can certainly work around it by skipping that stage (and risking missing something in the templates) OR one can go through the trouble of finding manually what the problem with Whonix is and how to fix it.

Even though this is a problem with Whonix, I'd argue that Qubes could give some help here given that whonix is installed by default. Would it be possible to help users work around this issue, at least for the inplace upgrade?

Here are some ideas:

1. At the end of STAGE 1 giving the user an option to continue with some failed updates (at their own risks)
2. Add a step to STAGE 1 just before qubes-vm-update that (in case Whonix templates) exist "qvm-runs" the necessary workaround indempotently (to accommodate already-fixed systems)

Best regards,

deeplow

[Demi Marie Obenour]

On 2/1/26 08:47, 'deeplow' via qubes-devel wrote:
> [A key expiration issue](https://forums.whonix.org/t/expkeysig-error-gpg-key-whonix/22721) is currently effectively preventing updating Whonix qubes in Qubes 4.2 and [it requires manual intervention](https://www.kicksecure.com/wiki/EXPKEYSIG) in order to be fixed. This is a problem in itself that is probably affecting a significant number of users who have not yet migrated to 4.3. But the problem is exacerbated because the Qubes inplace upgrade too cannot finish "STAGE 1" if a qube fails to update.

>
> This results in a potential problem for users: the current in-place upgrade instructions will fail on default installations and the users will never be able to pass STAGE 1. One can certainly work around it by skipping that stage (and risking missing something in the templates) OR one can go through the trouble of finding manually what the problem with Whonix is and how to fix it.
>
> Even though this is a problem with Whonix, I'd argue that Qubes could give some help here given that whonix is installed by default. Would it be possible to help users work around this issue, at least for the inplace upgrade?
>
> Here are some ideas:
>

> - At the end of STAGE 1 giving the user an option to continue with some failed updates (at their own risks)
> - Add a step to STAGE 1 just before qubes-vm-update that (in case Whonix templates) exist "qvm-runs" the necessary workaround indempotently (to accommodate already-fixed systems)
>
> Best regards,
> deeplow

Thanks for bringing this up! I chose to continue despite the failed
Whonix 17 updates, and then replaced the Whonix 17 templates with the
Whonix 18 ones. This meant the Whonix 17 templates only had to last
long enough to download the new packages, which they did.
--
Sincerely,
Demi Marie Obenour (she/her/hers)