Cannot Update Whonix Qubes Due To Invalid Signature

User Support General
1

Today running Qubes Update failed on templates whonix-gateway-17 and whonix-workstation-17 (with two tries), due to an invalid signature, possibly of @adrelanos

Can someone please check what’s going on?

An excerpt of the relevant error messages is appended below.

Thanks in advance for any help,
ChildsPose

W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: tor+https://deb.whonix.org bookworm InRelease: The following signatures were invalid: EXPKEYSIG CB8D50BB77BB3C48 Patrick Schleizer adrelanos@kicksecure.com

1 Like
2

I don’t have 17 but have Whonix 18 instead and those ones aren’t having any issues right now.

(IMG) Example

Screenshot_2026-01-24_10-46-21
Screenshot_2026-01-24_10-46-21777×987 86.6 KB

I would update to use Whonix 18 as 17 will be depreciated on February 6th, 2026:

2 Likes
3

There’s also a thread about this in the Whonix forum:

As stated in that announcement, Whonix 17 on Qubes 4.2 is supposed to be supported for as long as Qubes 4.2 receives security updates, which is currently scheduled to be until 2026-06-21 (six months after the release of Qubes 4.3, per the standard Qubes release support policy).

(CC: @marmarek)

4 Likes
4

Thank you very much for referring me to that thread.

Yes, am in the same situation, on Qubes 4.2.

1 Like
5

In R4.2 I fixed it with this: EXPKEYSIG

3 Likes
6

Whonix 18 templates for Qubes 4.2 would be nice. Some have been hesitant to get in the Qubes 4.3 pool.

2 Likes
7

This should be done in dom0?

1 Like
8

Preferably, avoid doing anything in dom0 whenever possible. The commands in the linked documentation are meant to be run in the template and should work for most users.

But you can also do this: Download the key in any VM, verify the fingerprint, copy it to the Whonix template VMs and standalones and place it in /usr/share/keyrings/derivative.asc. Just as good. I personally prefer doing as little as possible in the template.

2 Likes
9

How do I add the new key into the Whonix Workstation template? I cannot execute sudo, the ability to do that was removed like half a year ago. And the linked instructions assume I can execute sudo?

[template workstation user ~]%  sudo http_proxy=http://127.0.0.1:8082 https_proxy=http://127.0.0.1:8082 curl --tlsv1.3 --output /usr/share/keyrings/derivative.asc --url https://www.kicksecure.com/keys/derivative.asc 
zsh: permission denied: sudo
zsh: exit 126   sudo http_proxy=http://127.0.0.1:8082 https_proxy=http://127.0.0.1:8082 curl

I also want to know what action is taken by Whonix team to prevent this from ever happening again. Bricking software updates for everyone like this for a security and privacy critical piece of software is of course a major issue. Not all activists and journalists that depend on Whonix may be able to repair their installation, or even realize they must, putting them in great danger. @adrelanos

Is there anything the QubesOS team can do to repair existing installations, through a dom0 update? @marmarek

1 Like
10

sudo/root wasn’t made totally inaccessible.

There are existing forum threads in Whonix forums. Probably also in Qubes forums.

In short, in Qubes R4.2 use a Qubes Root Console. More information:

Please use existing forum thread(s) in case more discussion on sudo/root is required to avoid duplicating these here.

The latest version of the signing key has no expiration date.

(If I try really hard, an argument can be made with an expiration date would be preferable but in the grand scheme of things, these kinds expiresig issues are much worse.)

Not planned. Rationale: EXPKEYSIG - Error GPG key Whonix - #14 by Patrick - Support - Whonix Forum

2 Likes
11

Key expiration date, for the key used for the release channel, should be the software end of life date.
A developer on my team thought that was what you guys were doing when I first saw the key expired.

1 Like