Any way to check QUBES version of a Whonix template?

For example, I just downloaded GW and WS templates version 13. How can I know whether these are already set for Qubes version 3.2, or still stuck at 3.1 and need to be manually upgraded to 3.2?


1 Like

There is not a 1:1 correspondence between Whonix & Qubes versions nor are Whonix templates customized for individual Qubes versions. I believe the Whonix policy is to support all Qubes supported versions, so Whonix 13 currently supports R3.2 and R3.1.

1 Like

That’s actually not that simple indeed.

whonixcheck --verbose --function download_whonix_news                                                                                                        

Ignore most. The interesting part.

√ Up to date: whonix-workstation-packages-dependencies 3.4.2-1
√ Up to date: Whonix Build Version: 3:2.0-1

Or if not an old build…

cat /var/lib/anon-dist/build_version



  • qubes-template-whonix-gw-3.0.6-201612182342
  • qubes-template-whonix-ws-3.0.6-201612190628

If you reinstall the template, you should get the most recent stable. And if you are using currently the jessie repository, you should end up with latest stable packages.

Would it be helpful if we added a “Whonix” column or section to this page?

When I do either of these command I get:

√ Up to date: whonix-workstation-packages-dependencies 3.4.2-1
√ Up to date: Whonix Build Version:

…in my older template, but in the newly downloaded one:

√ Up to date: whonix-workstation-packages-dependencies 3.4.2-1
√ Up to date: Whonix Build Version: 3:2.0-1

Why does the older build show Whonix version properly (“12”) but newer one reference (presumably) Qubes version (“3:2”) ?

What I meant primarily in my question about “Qubes Version” of the template, is that here in this guide for updating Qubes from R3.1 to R3.2:

…It describes multiple steps for upgrading Debian/Whonix templates, and I wanted to know whether those steps have in theory already been “done” in newly downloaded Whonix 13 template, or whether they are still in an older R3.1 state and need to have these steps done. Specifically for example:

sudo cp /etc/apt/sources.list.d/qubes-r3.list /etc/apt/sources.list.d/qubes-r3-upgrade.list
sudo sed -i ‘s/r3.1/r3.2/’ /etc/apt/sources.list.d/qubes-r3-upgrade.list

Have those repos/sources already been updated in newly downloaded template, to reflect the changes above? Or does this need to be done manually after download?

Because Qubes-Whonix 13 was build without Whonix’s build script. (Just using Qubes Builder and qubes-template-whonix.) There is no anon_dist_build_version, so version number of the anon-base-files package is used as build version.

When it says up to date, it probably is, because it has to be manually added to the Whonix News Files.

If you are using the latest stable repository (at time of writing: jessie), there is virtually no way to end up with outdated package versions. Whonix APT repository need to be constantly resigned to refresh the latest signature time. Otherwise apt-get would show an error. So there is (presumed apt-get doesn’t have a security bug) no way to not catch a stale mirror attack.

Freshly downloaded (new installations or reinstallations) of templates do at the moment not require any manual fixups (besides usual apt-get upgrading). Templates for R3.2 come with Qubes R3.2 packages included.

(In theory if you just reinstall whonix-gw / whonix-ws but keep existing sys-whonix / anon-whonix there might be need a manual fixup in sys-whonix / anon-whonix but at the moment fortunately no such thing is required.)

Thanks. I actually noticed that when I downloaded brand new whonix-gw (v13) template and then just changed existing sys-whonix VM to use new template as its backing template, trying to start that old sys-whonix failed with errors about TORRC file having errors needing correction. Being too afraid to try such manual fixes, I instead just created a new fresh ProxyVM called sys-whonix-13 and made its template the new whonix-gw (v13) and that seemed to work okay. I presume nothing else additional is needed to configure new ProxyVM, other than set its template as the new one.

Yes, but we should sort out a few issues first to make all of this less confusing.

  • What to list there? Build versions and/or package versions?

  • From inside VMs it should be possible to detect their dom0 package versions. Probably won’t work, because there is no such version for clones.

  • Some better way to set anon_dist_build_version. Setting that for Qubes-Whonix to anon-base-files package version was clearly a bad idea by me. (Implementation was simple and robust, though.) Not such a big issue since users mostly don’t need to know about these details. Mostly used internally to detect and abandon no longer supported versions should that ever be required. (Obviously hopefully never.)

  • Perhaps anon_dist_build_version should be exported and set to qubes-template-whonix version. (git describe --always --abbrev=1000000000)

  • Why do qubes-template-whonix-gw / qubes-template-whonix-ws use package version 3.0.6-…? That is up for Marek to decide. I don’t know where he configures that. Perhaps package version should be rather Whonix like 13… 14… etc.?

We could just list both.

@marmarek, what are your thoughts?

qubes-template-* version is based on template builder version (version
file in linux-template-builder component). Since introduction of builder
plugins, this is basically some arbitrary (rather meaningless) number.
There are too much variables to include all of them in package version
(target Qubes version, Whonix version, etc). Template package release
(that timestamp) is also quite meaningless - it only uniquely identify
particular template, but doesn’t bring much information.

While theoretically we could try to have those numbers some more
meaningful, I think it doesn’t worth it - in any case this will be only
about initial state of the template. User is free to modify template
freely (for example perform in-place upgrade to newer Qubes version, or
Whonix version).

Also, currently VM have no way to learn that number.

Checking target Qubes version (in template) - check qubes-core-agent
package version.
Checking Whonix version - probably very similar using some other

1 Like