Btw it is always
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.
Btw it is always
Lack of knowing a more appropriate place this is documented here for now:
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
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
- or choose some working keyserver
- replace fingerprint with actual fingerprint
GPG_EXEis understood by
- possible to replace
bash -x apt-keyfor 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.
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.
Everything same results.
bash -x be used for better debug for many different commands or just a select few?
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
bash -xbe 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
Those written in
sh will say
#!/bin/sh and can be debugged with
sh -x program-name.
Onionizing updates -> Fixed
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:
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?
- Could you please use https://www.whonix.org/wiki/Template:Stable_Whonix_based_on_Debian_codename /
- One might still want to disable clearnet sources (while keeping onion sources).
Qubes apt sources list:
These apt-key / gpg commands are functional now.
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.
Qubes R4 Only
Qubes R4 users must also install qubes-core-admin-addon-whonix from Qubes’ dom0 stable repository. 
sudo qubes-dom0-update qubes-core-admin-addon-whonix
Update qubes-mgmt-salt-dom0-virtual-machines. 
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. 
sudo qubesctl top.enable qvm.whonix-testing pillar=true
@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.
Reinstallation is still confusing.
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.
I’ll submit again once I correct the mistakes.
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.)
I misunderstood the options to submit a patch. Will use for & pull requests next time.
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
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?
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.
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
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]].
it has not changed at the moment, @torjunkie. if it does, i’ll handle the wiki edits.