[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Long Wiki Edits Thread

Website
#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:
https://www.whonix.org/wiki/Dev/Qubes#Connection_through_Qubes_Updates_Proxy

#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… random development log 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:
https://github.com/QubesOS/qubes-issues/issues/2623

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
#853

@tempest - please give me the heads up if the Encrypted Email guide has changed with Whonix 14 release.

If you’re keen, you could make any changes to the wiki. If not, point out the areas that need reworking; then I’ll just use your updated guide as a reference.

1 Like
#854

Reinstallation is still confusing.

#855

Submitted patches to qubes-devel mailing list but have not received any response. Followed instructions https://qubes-os.org/doc/source-code/#how-to-send-patches but it looks like I didn’t format the patch correctly.

https://groups.google.com/forum/#!topic/qubes-devel/8WM1wegSg90

https://groups.google.com/forum/#!topic/qubes-devel/G8dCAp-BRBo

I’ll submit again once I correct the mistakes.

2 Likes
#856

Marek is on vacation. Things will take a while.

Send a patch to the qubes-devel mailing list (git format-patch). seems antiquated. I’ve never bothered with it.

Much better to send a github pull request. (Preferred: Use GitHub’s fork & pull requests.)

#857

I misunderstood the options to submit a patch. Will use for & pull requests next time.

2 Likes
#858

I could use help with some public communications. These are two recent e-mails to the Qubes mailing lists.

Looks like the Qubes mailing lists are kinda disconnected from the Whonix community in the Whonix forums. Fewer people seemed to follow calls for testers there or being using the testers repository. I guess I lacked activity on that mailing list even if it would just be mirroring news.

  • please stay tuned on Whonix news

https://groups.google.com/forum/#!topic/qubes-users/ppdbaDAavRY

It is important to read the latest Whonix news to stay in touch with
ongoing developments. This way users benefit from notifications
concerning important security vulnerabilities and improved releases
which address identified issues, like those affecting the updater or
other core elements.

Read more:
https://www.whonix.org/wiki/Stay_Tuned
  • Whonix Testers Wanted!

(Somehow not on https://groups.google.com/forum/#!forum/qubes-users yet.)

Whonix needs more users using:

- Whonix stable-proposed-updates APT repository or
- Whonix testers APT repository

More information and how to switch Whonix APT repository:
https://www.whonix.org/wiki/Whonix-APT-Repository

These could be written a bit more eloquent with reasoning how and why this helps keeping Whonix stable and then reposted in a few days.

Didn’t we have a guide somewhere how to have some Whonix AppVMs using Whonix testers while others using Whonix stable as well?

1 Like
#859

Yes.

Somewhere it has words like:

Whonix requires a critical mass of users to properly test planned updates by enabling the proposed-updates or other testing repositories. Otherwise, bugs might be inadvertently introduced into to the stable repositories.

I don’t think it mentioned setting up an extra Whonix-WS and/or GW. Maybe:

To ensure a stable Whonix system is available at all times, willing testers should:

  • Create new Whonix-Workstation and Whonix-Gateway TemplateVMs solely for testing.
  • Enable the relevant repository via the Whonix repository tool.
  • Create a clean snapshot (non-Qubes-Whonix) or AppVM (Qubes-Whonix) for each TemplateVM, and perform normal user activites.

Bugs should only be reported after first searching in the forums and developer portals for whether they are already known.

1 Like
#860

Also, better not tag/link that “Windows Hosts” to the old Computer Security wiki page.

Once I have finished the million link fixes, 3 pages should be deleted:

  • Security Guide
  • Advanced Security Guide
  • Computer Security Education
1 Like
#861

Was wondering about it, I failed to find the new location.

Could you please remove them from /Documentation (and other links to these 3 pages) but on these 3 link from each chapter to the new location? That way a lot links could still be found. (I.e. for example Security Guide#some_anchor would say

# some anchor
Moved [[new location]].
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]