Long Wiki Edits Thread

Website
833

@Patrick

Whonix 14 Release forum post nits:

  • VirtualBox .ova and libvirt qcow2 raw images were reduced by 35% correct? (it says just .ova at the minute)
  • Remove that “prefers onion sources line”, since that is no longer true.

Other than that - congrats on the release! Lets see how everyone goes upgrading/re-installing…

1 Like
834

@Patrick

Please check my edits to upgrade instructions. One of those Qubes packages is now in the stable repo, not the testing one (I fixed that). But could be other minor errors.

Could be good to double check since Whonix 14 has been announced.

1 Like
835

torjunkie:

@Patrick

Whonix 14 Release forum post nits:

  • VirtualBox .ova and libvirt qcow2 raw images were reduced by 35% correct? (it says just .ova at the minute)

Yes. Could you please edit the post (given moderation power)?

  • Remove that “prefers onion sources line”, since that is no longer true.

It’s true. You might be misinterpreting some commit or forum message by me.

Other than that - congrats on the release! Lets see how everyone goes upgrading/re-installing…

:slight_smile:

836

OK, I’ll fix that.

http://phabricator.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/T812 ?

1 Like
837

I see. Ticket description improved.

1 Like
838

I was contemplating to drop support for Qubes R3.2. Makes development a
lot harder / time consuming to keep compatibility with both in mind.
Suffering from sunken cost fallacy.

0brand:

[quote=“Patrick, post:743, topic:3477”]
This very chapter: https://www.whonix.org/wiki/Dev/Qubes#Connection_through_Qubes_Updates_Proxy
Could you please test? And document a bit better?

Also the following…

Qubes R3.2

http_proxy=http://10.137.255.254:8082 gpg.anondist-orig --recv-keys ...

Please forget about doing this in a TempalteVM for a second for testing
purposes. Does the gpg --recv-keys key work for you?

This is what is happening for me in a Debian VM.

gpg --recv-keys “916B 8D99 C38E AF5E 8ADC 7A2A 8D66 066A 2EEA CCDA”
gpg: keyserver receive failed: Server indicated a failure

http_proxy=http://10.137.255.254:8082 curl.anondist-orig check.torproject.org works for me in Qubes-Whonix 14 Qubes R3.2. Does
that work for you?

Qubes R4

http_proxy=http://127.0.0.1:8082 gpg.anondist-orig --recv-keys ...

Would then be possible. What would be a good place to document this?
[/quote]

Does http_proxy=http://127.0.0.1:8082 gpg.anondist-orig check.torproject.org work for you in Qubes-Whonix 14 Qubes R4?

The goal is for connecting without enabling networking in TemplateVMs? Correct?

Correct.

839

Sounds reasonable with only 6 months left on that anyway.

PS Whonix 14 upgrade seems ok. However:

  • Steps for install qubes-whonix-workstation (and gateway) are not necessary. They are already installed before that step.
  • Ditto the dom0 qubes-whonix-add-on (or whatever it’s called) - it’s already installed somewhere before that step.
  • The qubes salt stuff to create the anon-whonix didn’t work for me (similar to mig5 from memory). Had to manually create one from Qubes Manager. I trust that is safe with anon-vm tags now (?) If not, how to check for tags etc?
1 Like
840

torjunkie:

Sounds reasonable with only 6 months left on that anyway.

PS Whonix 14 upgrade seems ok. However:

  • Steps for install qubes-whonix-workstation (and gateway) are not necessary. They are already installed before that step.

Confirmed. Should be kept anyhow. This is only a safeguard to make sure Whonix distribution defaults as far as default package selection are enforced. Will only matter for users who previously uninstalled a Whonix meta package.

  • Ditto the dom0 qubes-whonix-add-on (or whatever it’s called) - it’s already installed somewhere before that step.

Right, it is now a dependency of qubes-mgmt-salt-dom0-virtual-machines. Therefore can be removed.

  • The qubes salt stuff to create the anon-whonix didn’t work for me (similar to mig5 from memory). Had to manually create one from Qubes Manager.

Error message? Was any TemplateVM / sys-whonix / anon-whonix already
existing? You mean iry / No error information when salt failed to create a VM due to name collision · Issue #4177 · QubesOS/qubes-issues · GitHub ?

I trust that is safe with anon-vm tags now (?)

Don’t. :wink: TODO: add missing Whonix tags anon-vm / anon-gateway to user created Whonix based VMs · Issue #4155 · QubesOS/qubes-issues · GitHub - But also don’t worry much about it for now as per Dev/Qubes - Whonix (just now written).

If not, how to check for tags etc?

Just now documented all of that:
Dev/Qubes - Whonix

1 Like
841

It would certainly benefit Qube-Whonix development. Easier for everyone: devs., mantainers, etc

Same result

Yes both work

Neither one works

http_proxy=https://127.0.0.1:8082 curl.anondist-orig https://check.torproject.org curl: (6) Could not resolve host: check.torproject.org

http_proxy=http://127.0.0.1:8082 gpg.anondist-orig --recv-keys 0x427F11FD0FAA4B080123F01CDDFA1A3E36879494 gpg: keyserver receive failed: No keyserver available

2 Likes
842

0brand:

gpg --recv-keys “916B 8D99 C38E AF5E 8ADC 7A2A 8D66 066A 2EEA CCDA”
gpg: keyserver receive failed: Server indicated a failure

That is a general gpg bug unrelated to Qubes / Whonix / TemplateVMs. Could you open a new thread for this please so someone can investigate?

Qubes R4 / Whonix 14> `http_proxy=http://127.0.0.1:8082 curl.anondist-orig https://check.torproject.org

Let’s concentrate on this one since it is the easier one. One connection work (and once gpg works) it’s easy to replace curl with gpg on the command line.

Qubes R4 / Whonix 14 works for me:

http_proxy=http://127.0.0.1:8082 curl.anondist-orig check.torproject.org

Qubes R4 / Whonix 14 broken:

http_proxy=http://127.0.0.1:8082 curl.anondist-orig https://check.torproject.org

This looks like a bug in curl. Looks like curl tries to resolve DNS without using the proxy when using https destination (https://check.torproject.org ).

Qubes R4 / Whonix 14 works for me:

curl.anondist-orig --proxy http://127.0.0.1:8082 https://check.torproject.org

I guess that also works for you?

1 Like
843

Btw it is always http_proxy=http. Never http_proxy=https. This is because it’s a local proxy. Even https would work there, that would be ok. But it wouldn’t use encryption / use certificates. It only means http connect.

844

Lack of knowing a more appropriate place this is documented here for now:
Dev/Qubes - Whonix

845

Qubes doesn’t like my idea of dropping R3.2

If you like to experiment… R3.2:

sudo GPG_EXE=gpg.anondist-orig apt-key adv --keyserver keyserver --keyserver-options http-proxy=http://10.137.255.254:8082 --recv-keys fingerprint

R4:

sudo GPG_EXE=gpg.anondist-orig apt-key adv --keyserver keyserver --keyserver-options http-proxy=http://127.0.0.1:8082 --recv-keys fingerprint
  • might be able to drop --keyserver keyserver
  • or choose some working keyserver
  • replace fingerprint with actual fingerprint
  • variable GPG_EXE is understood by apt-key
  • possible to replace apt-key with bash -x apt-key for better debug

When you get gpg: keyserver receive failed: Server indicated a failure means the Qubes TemplateVM connectivity side is solved, then you “only” need to workaround / configure / solve that gpg bug.

846

Looking into apt-key let me stumble upon something I always wanted to figure out… miscellaneous development log - #29 by Patrick Anyhow.

Once working please refine the apt-key command by adding --keyring /etc/apt/trusted.gpg.d/reponame.gpg. Much much cleaner than adding to /etc/apt/trusted.gpg! Also then instructions to disable it are as simple as sudo rm /etc/apt/trusted.gpg.d/reponame.gpg.

847

Done.

https://forums.whonix.org/t/gpg-recv-keys-fails/5607

OK

Everything same results.

Understood

OK :slight_smile:

Can bash -x be used for better debug for many different commands or just a select few?

OK.

1 Like
848

0brand:

https://forums.whonix.org/t/gpg-recv-keys-fails/5607

Thanks!

Once that is sorted a single call of apt-key can work inside TempalteVM, fetch the right key and add to right location. Something like this could do:

sudo GPG_EXE=gpg.anondist-orig apt-key --keyserver-options http-proxy=http://127.0.0.1:8082 --keyring /etc/apt/trusted.gpg.d/whonix.gpg adv --keyserver keys.gnupg.net --recv-keys 916B8D99C38EAF5E8ADC7A2A8D66066A2EEACCDA

Can bash -x be used for better debug for many different commands or just a select few?

Only the ones written in bash. To find out which program-name. Open
in an editor.

kwrite `which apt-key`

The first line will say #!/bin/bash.

Those written in sh will say #!/bin/sh and can be debugged with sh -x program-name.

849

Onionizing updates → Fixed

@Patrick

The onionizing of Whonix (v3) and Debian (v2) package updates is nice, so the user no longer needs to manually edit /etc/apt/sources.list.d/debian.list etc in Qubes-Whonix templates.

However, I note that in Debian and Whonix templates, we have:

qubes-r4.list

which is using the clearnet resources, instead of presumably the v3 .onion i.e.

http://sik5nlgfc5qylnnsr57qrbm64zbdx6t4lreyhpon3ychmxmiem7tioad.onion/

This is an obvious (and relatively safe) feature improvement, since we already host the Qubes .onion as I understand it i.e. we trust the same infrastructure for Whonix package updates over onion services.

So this is an easy candidate for stretch-proposed-updates i.e. update sources.list.d in that qubes list for R3.2 and R4?

1 Like
850

onionizing:

Qubes apt sources list:

1 Like
851

These apt-key / gpg commands are functional now.

1 Like
852

@Patrick

Tried to clean up Qubes/Install to reduce user confusion i see in forums etc.

Also, you sure we still need all this at the bottom here for the separate upgrade instructions? That testing pillar command looks out of place too in terms of sequence and not explained why/if user would want to do that.

http://dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Upgrading_Whonix_13_to_Whonix_14#Qubes_R4_Only

Qubes R4 Only

Qubes R4 users must also install qubes-core-admin-addon-whonix from Qubes’ dom0 stable repository. [12]

sudo qubes-dom0-update qubes-core-admin-addon-whonix

Update qubes-mgmt-salt-dom0-virtual-machines. [13]

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-mgmt-salt-dom0-virtual-machines

The following command will configure Qubes dom0 salt to use Qubes’ community-testing-repository for downloading Whonix. [14]

sudo qubesctl top.enable qvm.whonix-testing pillar=true

1 Like