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.
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 ).
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.
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.
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.
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.
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?
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.
@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.
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.
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 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?
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.