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.
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 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.
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
I was just hoping for a clean execution of those pages. Dev pages etc wouldn’t reference them much (?) anyway. Then any red links are easily located and fixed via broken links function on wiki I believe.
Perhaps my text further up can go into the “testers” wiki page in Introduction section on why we need testers etc.
(that page badly needs a revamp - will get to that later on after links maybe)
Other nit:
That setting Tor Browser pre-pended with firejail didn’t work for me. Must be set in the templateVM? I thought that .d location in anon-whonix was persistent, but probably wrong. (should be noted in that section one way or another)
Why do we have AppArmor enforcement examples for anon-whonix, when settings are inherited from TemplateVMs anyway? Someone who only wants a session of AppArmor due to possible conflicts or other reason?
Passwords page - without researching it, I thought from memory computers / software weren’t to be trusted for password generation due to possible exhausted entropy pools or similar shit. That is the basic idea to go with dice, and leave the fancy computer stuff off the table in general for safety.
(I’m sure you have some good reference or idea one way or the other. Lets not leave these TODOs lying around unnecessarily if they are easily answered or footnoted)
Please also check my edits on guard fingerprinting to address what you and adw raised.
These may be referenced tons of times in the forums / on external websites. We could/should __NOINDEX__ these pages to hide outdated location from search engine results so the new docs locations get picked up by search engines. It’s not critical but good to have.
Btw would it help if you had access to wiki mass search and replace?
Yes.
In TemplateVM: /etc/torbrowser.d/50_user.conf
or
In TemplateBasedVM: /rw/config/torbrowser.d/50_user.conf; do
set
tb_starter_bin_pre=something...
To debug:
bash -x torbrowser
It’s only inherited if TemplateBasedVM is created after TemplateVM had the setting by the time of the creation of the TemplateBasedVM. This leaves a gap for users who do it later.
Reinhold writes a bit about physical dices not being perfect either. casino-grade dice might be better.
Think about this for a moment: whoever wrote the /dev/random
manual page seems to simultaneously believe that
(1) we can’t figure out how to deterministically expand one 256-bit
/dev/random output into an endless stream of unpredictable keys
(this is what we need from urandom), but
(2) we can figure out how to use a single key to safely encrypt
many messages (this is what we need from SSL, PGP, etc.).
For a cryptographer this doesn’t even pass the laugh test.
Sure thing, very happy to!
That was totally off my radar. Thanks for reminding me. Guess I’ll search upwards in this thread here to find it.
