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.
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 byapt-key
- possible to replace
apt-key
withbash -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.
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
.
Done.
https://forums.whonix.org/t/gpg-recv-keys-fails/5607
OK
Everything same results.
Understood
OK
Can bash -x
be used for better debug for many different commands or just a select few?
OK.
0brand:
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
.
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:
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?
onionizing:
- Could you please use https://www.whonix.org/wiki/Template:Stable_Whonix_based_on_Debian_codename /
{{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. [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
@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.
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.
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
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 Redirecting to Google Groups 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?
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.
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]].