Whonix-17

janglingquo_575 · December 6, 2023, 12:57am

Is Whonix-17 template available yet?

Minio · December 6, 2023, 2:01am

In Qubes 4.2 it is: Supported releases | Qubes OS

janglingquo_575 · December 7, 2023, 2:17am

Have you tried downloading it yet? I attempted to list it via dom0 cli using

qvm-template --enablerepo=qubes-templates-community-testing list --available

but only whonix-16 is actually listed, not 17

the mirror tried is:

https://mirrors.edge.kernel.org/qubes/repo/yum/r4.2/templates-community-testing/rpm/

Minio · December 7, 2023, 3:22am

Your command works for me. Are you sure you’re using Qubes 4.2 and also realize that whonix-gw-* and whonix-ws-* have been renamed to whonix-gateway-* and whonix-workstation-*?

janglingquo_575 · December 7, 2023, 3:43am

I checked my repos in /etc/yum.repos.d/ and realized they might be out of date. I have the following repos:

3isec-dom0.repo
fedora.repo
fedora-updates.repo
qubes-dom0.repo
qubes-templates.repo

adw · December 7, 2023, 8:32am

To check your Qubes OS version, go to Qube Manager → About → Qubes OS.

janglingquo_575 · December 7, 2023, 4:01pm

It is 4.1.2 the latest stable release.

I checked my repos in /etc/yum.repos.d/ and realized they might be out of date. I have the following repos:

3isec-dom0.repo
https://qubes.3isec.org/rpm/r4.1/current/dom0/fc32/

fedora.repo
http://download.fedoraproject.org/pub/fedora/linux/releases/32/everything/x86_64/os/

→ Should this be switched to f38?

fedora-updates.repo
http://download.fedoraproject.org/pub/fedora/linux/updates/32/x86_64/

qubes-dom0.repo
http://yum.qubesosfasa4zl44o4tws22i6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/4.2/current/dom0/fc32

qubes-templates.repo

http://yum.qubesosfasa4zl44o4tws22i6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/4.2/current/dom0/fc32

→ Is this the best .onion repo?

One trend I noticed is that all of the versions are f32, not f38 or f39

janglingquo_575 · December 7, 2023, 4:42pm

Are you able to install Whonix-17? Which repo did you use?

apparatus · December 7, 2023, 5:35pm

Can I use Whonix 17 on Qubes 4.1?

No

github.com/QubesOS/qubes-issues

Coordinate release of Whonix for R4.2

opened 10:22PM - 02 Dec 22 UTC

closed 03:25AM - 03 Sep 23 UTC

marmarek

T: task P: blocker C: Whonix

[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/) #…## Qubes OS release (if applicable) 4.2 ### Brief summary This is place to coordinate release of Whonix for Qubes R4.2 with @adrelanos I'll be doing some test template builds, but those aren't meant to be final. Generally, I don't expect any compatibility issues, but that needs to be tested.

apparatus · December 7, 2023, 5:44pm

github.com/QubesOS/qubes-issues

Qubes-Whonix 16 security support / Qubes R4.2 stable release date

opened 01:29PM - 07 Dec 23 UTC

adrelanos

T: bug C: Whonix P: default

Debian is not going to fix a Tor vulnerability for Debian 11 (bullseye). http…s://security-tracker.debian.org/tracker/TEMP-0000000-7CC552 That I take by the table on the Debain website marking the Tor version for that Debian release as "end-of-life". Hence Whonix 16 (Debian 11, bullseye based) won't get the fix either by any Debian package upgrade. It seems and more and more that Qubes-Whonix 16 should be deprecated. Backporting the fix to Whonix 16 be a major hassle and I don't see much point in it either staying on outdated bullseye (what Whonix 16 is based on). That seems that worst solution to me. Qubes 4.2 seems to be stuck in RC land. Now at 4.2.0-rc5. "For a full list of open bug reports affecting 4.2, please see here." https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+label%3Aaffects-4.2+label%3A%22T%3A+bug%22+is%3Aopen There is 161 bugs there. So I doubt these would all be fixed. Also for previously releases there have been tons of bugs there assigned to that release that after the release were ignored. Long story short, what's the ETA for Qubes 4.2? Days, weeks, moths, years? Maybe I should have stayed on Qubes 4.1 and supported Whonix 17 (Debian 12, bookworm based) on Qubes 4.1 only. I didn't expect that Qubes 4.2 release to go up to rc5. Usually rc3 was the last RC before final release if I am not mistaken. If Qubes 4.2 is going to be stuck in RC land for much more time then perhaps Whonix 17 needs to be released for Qubes 4.1 if that is still worth it? Also something that I would like to avoid because it would be clunky to keep testing everything for two different Qubes releases R4.1 and R4.2. Main things to test: * APT does not break due to dependency conflicts * Tor connectivity does not break (and hopefully does not break in weird ways such as it works but fails to download bigger files as in [Tor 0.4.8.9 broken in combination with vanguards](https://gitlab.torproject.org/tpo/core/tor/-/issues/40892). This would also make future development harder such as Whonix port to nftables. (https://github.com/QubesOS/qubes-issues/issues/8562) This is because then I would have to see if Qubes R.4.1 works with nftables, lead test both, etc. Also something I'd rather avoid. Maybe next time I should stay on Qubes stable longer before switching to Qubes RC. So both solutions seem awful (A), effort spent on security support for Debian 11 bullseye Whonix 16 and B) Qubes-Whonix 17 for maybe soon outdated Qubes R4.1) My favorite solution would be Qubes R4.2 to be blessed stable so a Qubes-Whonix 16 deprecation notice can be released. Update: Debian 11 in Qubes R4.1 has the same issue of a Tor vulnerability that won't be fixed by Debian.

adw · December 8, 2023, 12:10pm

Answered here:

Whonix 17 is not available for Qubes 4.1:

janglingquo_575 · December 8, 2023, 1:52pm

The summary listed here suggests that Whonix-16 should be deprecated; Is Whonix-16 stable on R4.1.2?

github.com/QubesOS/qubes-issues

Qubes-Whonix 16 security support / Qubes R4.2 stable release date

opened 01:29PM - 07 Dec 23 UTC

closed 11:31AM - 08 Dec 23 UTC

adrelanos

T: bug R: not applicable C: Whonix P: default

Debian is not going to fix a Tor vulnerability for Debian 11 (bullseye). http…s://security-tracker.debian.org/tracker/TEMP-0000000-7CC552 That I take by the table on the Debain website marking the Tor version for that Debian release as "end-of-life". Hence Whonix 16 (Debian 11, bullseye based) won't get the fix either by any Debian package upgrade. It seems and more and more that Qubes-Whonix 16 should be deprecated. Backporting the fix to Whonix 16 be a major hassle and I don't see much point in it either staying on outdated bullseye (what Whonix 16 is based on). That seems that worst solution to me. Qubes 4.2 seems to be stuck in RC land. Now at 4.2.0-rc5. "For a full list of open bug reports affecting 4.2, please see here." https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+label%3Aaffects-4.2+label%3A%22T%3A+bug%22+is%3Aopen There is 161 bugs there. So I doubt these would all be fixed. Also for previously releases there have been tons of bugs there assigned to that release that after the release were ignored. Long story short, what's the ETA for Qubes 4.2? Days, weeks, moths, years? Maybe I should have stayed on Qubes 4.1 and supported Whonix 17 (Debian 12, bookworm based) on Qubes 4.1 only. I didn't expect that Qubes 4.2 release to go up to rc5. Usually rc3 was the last RC before final release if I am not mistaken. If Qubes 4.2 is going to be stuck in RC land for much more time then perhaps Whonix 17 needs to be released for Qubes 4.1 if that is still worth it? Also something that I would like to avoid because it would be clunky to keep testing everything for two different Qubes releases R4.1 and R4.2. Main things to test: * APT does not break due to dependency conflicts * Tor connectivity does not break (and hopefully does not break in weird ways such as it works but fails to download bigger files as in [Tor 0.4.8.9 broken in combination with vanguards](https://gitlab.torproject.org/tpo/core/tor/-/issues/40892). This would also make future development harder such as Whonix port to nftables. (https://github.com/QubesOS/qubes-issues/issues/8562) This is because then I would have to see if Qubes R.4.1 works with nftables, lead test both, etc. Also something I'd rather avoid. Maybe next time I should stay on Qubes stable longer before switching to Qubes RC. So both solutions seem awful (A), effort spent on security support for Debian 11 bullseye Whonix 16 and B) Qubes-Whonix 17 for maybe soon outdated Qubes R4.1) My favorite solution would be Qubes R4.2 to be blessed stable so a Qubes-Whonix 16 deprecation notice can be released. Update: Debian 11 in Qubes R4.1 has the same issue of a Tor vulnerability that won't be fixed by Debian.

For 4.1.2 should it instead be running whonix-15?

adw · December 10, 2023, 4:05am

@janglingquo_575, please see the “Qubes Version Support” row in this table: