Microcode needs to be installed on the host.
- Not the default in Linux, Debian?
dpkg -l | grep microcode - Default in Qubes? dom0:
dnf list | grep microcode
1 Like
Thanks mig5. All very sane advice.
@0brand - I nitpicked your EOL announcement. Hope that’s okay (good job BTW 
)
3 Likes
Small nitpick: ARM is less affected and the processor in the rpi is not affected at all. In case your processor is affected you should always install patches on the host/bare metal.
1 Like
All fixed.
I didn’t add that to that Firmware section. You want those steps there somewhere?
Fixed.
And not widely known in community / explained in wiki (much). Hence why Xen only has low 100s in identified bugs, where Linux / Microsoft is through the roof. Will note & add that link to microkernel research i.e. you’re screwed on normal Linux platform by comparison.
Yet another reason to run Qubes, and have a small target at the core of your system.
2 Likes
torjunkie:
All fixed.
I didn’t add that to that Firmware section. You want those steps there somewhere?
In firmware section and linked to it from related places.
1 Like
Kernel versions and security / Debian backports reminds me… System Hardening Checklist
sudo apt-get install -t stretch-backports linux-image-amd64 linux-headers-amd64
Do we have this documented somewhere?
No not documented for the kernel.
1 Like
Updated Electrum documenation
https://whonix.org/w/index.php?title=Electrum&diff=36329&oldid=36328
Unfortunately when taking screenshots for electrum the screen would not shrink to a smaller size. Only during configuration though. Had to use larger size screenshots than normally would have.
I’ll work on this then I’d like to complete the Qubes/DispVM TODO’s
Edit:
torjunkie, I’m working on those flash screenshots to. Actually already have them but the information would not fit on one screen. (large gap between information) Trying to neatly cut and paste both screenshots together.
Patrick, I can start experimenting with:
2 Likes
electrum! Yes! 
Could you please notify the forum discussion threads?
update vs upgrade - definition - meaning suggesting and finding consensus among what update means, what upgrade means. Like word reference.
Fixed WS and GW size (in template) based on your forum thread i.e. around 50% reduction:
- 850 MB (GW)
- 1.1 GB (WS)
Let me know right away if that isn’t right. Also updated Whonix 14 release forum post, which had incorrect figures.
The Whonix-Gateway is reduced from 1.7 GB to 850 MB, while the Whonix-Workstation is reduced from 2 GB to 1.1 GB.
Fixed. Although I didn’t add HulaHoop’s step below (because I just saw it). Can add if you want:
Compare your microcode version number before and after updating to see if its applied:
sudo dmesg | grep “microcode updated early to”
If it succeeded it should say something like:
microcode: microcode updated early to revision X
In the process of fixing… we should recommend for host AND Whonix VMs right? So add to “Host Security” page of Basic Security Guide - seems like a nice fit there and Whonix-WS and Whonix-GW security pages for VM kernel I suppose.
Good job 0brand. You are getting some very solid contributions under your belt, and I for one welcome it! More please 
3 Likes
Done!
2 Likes
Yes please.
2 Likes
@Patrick My bad. I thought that Debian had added a v3 onion repo but it was a Whonix url I was changing it to. Good catch.
Do you think we should recommend the onion address as a safer default, considering tht we will be transitioning to a fully onion repo list soon.
I don’t expect too soon. Waiting Debian onion v3 (to proof Tor onions can handle the load) and maybe for onionbalance v3:
Onionizing Qubes-Whonix Repositories - #23 by mig5
Onionizing Repositories could say “for better security, disable clearnet and leave onions only”. Added that but undocumented.
Onionizing Repositories has some imperfections.
-
sudo nano- nano vs graphical editor
- do we have a wiki template for that?
- we have Template:Open with root rights - Whonix but that is for Whonix only, not guaranteed to work outside of Whonix (actually fails in Qubes Debian templates since these don’t have kwrite installed by default)
-
/etc/apt/sources.list.d/debian.list- Whonix: correct
- plain Debian hosts and Qubes Debian template: incorrect, it’s
/etc/apt/sources.list
-
Maybe instructions shouldn’t be by Debian packages, Whonix packages, Tor packages, Fedora packages. Perhaps better instructions for:
- Qubes dom0
- Qubes-Whonix TemplateVMs
- Qubes Debian TemplateVM
- Qubes Fedora TemplateVM
- Non-Qubes-Whonix
- plain Debian hosts
-
Then each chapter could contain instructions to onionize it as much as possible.
- Whonix: from onions/clearnet to exclusive onions
- others: from clearnet to exclusive onions
1 Like
As discussed with Marek and adw.
As for future Whonix support timelines… To have something doable…
-
once a new stable Qubes version is released, shortly after, there might be a 1 month notice to upgrade to that newer version of Qubes if users wish to keep using Qubes-Whonix
-
once a new stable Qubes-Whonix version is released, shortly after, there might be a 1 month notice to upgrade Qubes-Whonix if users wish to keep using Qubes-Whonix
-
once a new stable Non-Qubes-Whonix, shortly after, there will be a 1 month notice to upgrade Whonix if users wish to keep using Whonix
-
once a new stable Debian is released, shortly after, there might be a 1 month notice to upgrade Debian, if users wish to keep using Whonix
<ref>This is to relieve Whonix developers from having to diagnose and support old-stable versions of Qubes/Debian/Whonix which results in a lot duplicate maintenance effort.</ref>
Where can we add this support policy?
1 Like
Whonixnews, sticky on the Qubes subforum and a notice at the top of the Qubes main wiki page?
2 Likes
Added info to the About page to pick this issue up.
Might clean up some more links before fixing up that kernel stuff, but I’ll get there soon enough
1 Like
corridor -> Fixed.
There is one TODO there i.e. non functional bridges config.
Also, there is one table in the FAQ wiki page saying “Ignore for now. Broken since shift” or similar (Tails vs Whonix comparison). Can we just get rid of that or update the links or whatever?
Also, that Browser Plugins page is very messy.
Based on technically capable 0brand not being able to get Flash working in Tor Browser by:
a) installing flash player (non-free) from Debian; or
b) manually installing it from Adobe
and Tor Project blocking all plug-ins by default (I gather some about:config changes etc maybe also needed?), then 90% of Whonix users are not going to be capable of this, if it is even possible at all?
Has anyone got Flash working in recent Tor Browser versions?
I recommend, based on Flash:
- being phased out by most websites
- also being a security nightmare
- many other safe ways to access same media e.g. downloading tools etc.
- plus that wiki page quoting 5 year old JonDos info that just doesn’t work.
That we deprecate all the Flash instructions and point any intrested users to deprecated section i.e. it’s their own problem to work it out.
Why work hard to help users shoot themselves in the foot and fail to learn proper (safe) practices? Waste of time.
1 Like
The likely scenario would be a user installing Firefox in Whonix-Workstation then installing flash. Both of which are recommended against.
At current time there isn’t much that is useful in that chapter. Cleaning up that page is on my TODO but how useful will it be even after that is done? Can’t install any plugins in TBB.
Think it would be better to put our efforts into documentation that strengthens security /anonymity IMHO.
1 Like