Long Wiki Edits Thread

“Libre Software Development VS. Development in a Company” Chapter

Has been updated.

I see where I can condense subheadings

“Third Party Software” and " Making Changes to a Third Party Software" :slight_smile:

Here Unable to update Whonix - #10 by Patrick

1 Like

Not sure centralized vs decentralized is a useful concept here. For example, onionshare is centralized in Micah. And Whonix is centralized in me. Hard to truly decentralize it. I haven’t seen projects where it truely doesn’t matter much if the main developer vanishes.

Libre Software Development VS. Development in a Company

Maybe better compare Windows (same of Mac OS) and Linux distributions?

Important differences:

  • chain of command
  • authority to issue directives
  • possibility to deliver a unified experience (Windows) (CEO can issue directives to the developers of internet explorer to make it fit into the overall vision, guaranteed execution, fire on non-compliance)
  • patchwork rug (linux distributions can only pick what’s available, need to ask/contribute nicely while taking the perspective of the third party project)
  • funding
  • popularity

Maybe a comparison table?

This fits better at the bottom of the text perhaps to justify what’s the point of FLOSS if it’s such as patchwork rug.
(Related: Why Whonix ™ will always be Free as in Price as well as in Freedom)

The main desire of mine here was to explain to users who come from a nice unified usability experience. Like iPhone - you can complain about many things, but on the points of usability and a unified experience [no patchwork rug], you can’t complain. What I mean, lots of people come from an iPhone experience and then are going to demand the same from FLOSS. They’re entitled to their opinion and demand, but it makes sense to explain why things are as is.

Therefore this also doesn’t fit.

We have that here has The User Co-developer Concept .
Free Support for Whonix ™

Something like this.


I am sure, prorietary software development isn’t a piece of cake either but we don’t have to explain why that is.

companies: less about company vs non-company. There are also companies working on Open Source. It’s about proprietary (chain of command based development) vs libre distributions (patchwork rug).

Showing some examples is really good.

Companies refers to proprietary software, I guess. In these cases, they often don’t get the source code of third party software. So they can’t submit patches. Neither legal (nor feasible) to fork.


  • targeted at users expecting iPhone experience but getting linux distribution patchwork
  • rehash the forum posts I wrote before?
  • not so much a detail analysis of development inside a company vs open source development style (except: distribution maintainers can only ask nicely, even phrasing a nice request that gets understood is work)
1 Like

Hi @0brand,

There’s some good stuff there. I’m happy to edit it, but I guess I’ll wait for any reworking first.


It looks like- right idea, wrong interpretation . I assumed “company” meant a large well established project (had grown into a large open-source company) and maybe Whonix was a small open-source company. Oops :slight_smile:

This is probably one of the reasons why I was having so much trouble writing this.

I really appreciate you taking the time to get me pointed on the right track. I’ll start working on this right away!

Sound good. As soon as this is complete I’ll start on the “Qubes R4 adjustments for DisposableVMs”


A continually updated chart of mainline hardening defenses:

What would be an appropriate section to add a “kernel hardening status” section to for user reference?

Could this table (DispVM vs inheritance etc.) please be copied to the wiki?

For the changelog. Mostly fixes for Qubes R4 and DispVMs.


Maybe here?



I’ll find a home for this table as soon rewrite of Linux Distro vs Windows?? (not sure of title yet) is completed. This is going a little slow as well but I’m starting to make good progress. :slight_smile:


-> Fixed

Agree with 0brand, that might be a good location for Kernel stuff? Are you going to replicate all that in a mega-table @HulaHoop?

0brand, can you check the onionizing repositories stuff in the security guide? Nothing for Qubes R4, and I’m not sure those old instructions will work.

@Patrick, it’s pretty hard to make head or tails sometimes of those github links re: updates to Release Notes. Much easier from phabricator to see what is actually going on i.e. some basic description.

Also that Authorship page needs further clean up towards the bottom. I may well cut out Sources and 3rd party images to separate pages etc.

Edit: Tor 3.3.6 etc working fine in Qubes-Whonix. 3.3 series will make it to Whonix 14 stable repo I presume


I went through the onionizing repos docs (tested everything) and most of it looks good.

These are my proposed changes

1. Qubes onionizing: Fedora, Debian, Whonix Templates

Use a wildcard ( * ) in command lines so they work for both qubes-r3 and qubes-r4

Example: (tested, works)

.../etc/apt/sources.list.d/qubes-r3.list && cat /etc/apt/sources.list.d/qubes-r3.list'

.../etc/apt/sources.list.d/qubes-r* && cat /etc/apt/sources.list.d/qubes-r*'

2. Whonix and Debian Packages

Currently makes reference to “jessie” in section which users must copy and paste into their repo file.

#deb Index of /debian jessie main contrib non-free
deb http://vwakviie2ienjx6t.onion/debian jessie main contrib non-free

  • Perhaps make note that users should replace “jessie” with “stretch” when using Debian 9?
  • Once Whonix 14 is stable, change instructions to use “stretch”.

3. Onionize Tor Project Updates

Qubes R4: Since the connection fails when adding the Tor Project deb apt signing key in the TemplateVM. Make note for users to follow instruction in a StandaloneVM.

4. Change all instructions to use v3 .onions and make note of Qubes,Whonix v2 .onion addresses??

@torjunkie Thanks! I needed a little change of pace. :slight_smile:



In the onioizing Qubes packages command lines these are not considered varliables are they? If so they never worked.


It never made sense to me that instructions would have users onionize all TemplateVMs sinced your supposed to keep 1 template each for Debian Fedora etc. in unaltered state. For testing etc.I assumed users where required to replace e.g. $FedoraTemplateVM with Fedorea-26.

If I’m wrong that needs to be changed to



Too little thing for the effort of a StandaloneVM. gpg / apt-key can probably use networking when requests are going through Qubes updates proxy. Another option would be fetching the key in a networked VM and then copying it over as text or file.

1 Like

That would be great if you could fix those instructions 0brand! It all looks very sensible.

You are great with technical steps and breeze through that stuff. I’m actually very jealous :slight_smile:


No. too much unnecessary work. All I wanted was to point users to info on bug mitigation advancements in the kernel so they can assess their sec situation.


Double up in Anonymity System Comparison section:

Build script: apt-get unreliable exit code security workaround (Miscellaneous section)


apt-get unreliable exit code security workaround (Updates section).

Suggest you get rid of one or the other (or let me know).

1 Like

In case your wondering whats taking so long for the onionizing repos edits. I’m currently working on the above for Q4 users and and instructions to revert repositories back to http/URI (if needed).

This way I can get everything done at the same time. :slight_smile:


Comparison with Others -> Fixed.

(piece of cake, only 215 footnotes there…) :expressionless:

Next, finish off Authorship page, then split security guide as discussed earlier.


Realized that Screenshots page also badly needs updating:

a) logical structure
b) more categories
c) updated screenshots (particularly Qubes-Whonix)

Happy to snap away some shots, but surely many of these are already on the server.

Not sure if the easiest way to find images is Special:ListFiles ? or Special:NewFiles?

Also, as well as that idea for short list of cli commands for various entries, we should maybe put up a more pics at the top of each wiki entry, related to the topic? Make it look prettier and less encyclopaedic?

Reminder - @0brand - this page is always useful in the search bar ->




  • All Qubes commands now work for both R3 and R4
  • Changed all commands to use v3 addresses
  • Language edits: added infobox and also a few minor edits elsewhere
  • Workaround Instructions added to fetch Tor apt-key (Qubes R4)
  • More edits when Whonix 14 is blessed stable

Qubes onionizing instructions are a little confusing for less experienced users? If a typo was made in the .onion address they may not know how to correct the mistake. Tried adding minimal instructions using a text editor for mess up corrections and for reverting to http:// URI ( if necessary). But it just added clutter/confusion IMO

Onionizing Repositories

When Whonix, Debian and Qubes packages are installed or updated, default settings point to repositories with a http:// URI. [ref]Whonix ™ APT Repository However, experimental Tor onion services are already available for the Whonix, Debian and Qubes packages.

Utilizing Tor onion services provide several security and privacy benefits: [ref]https://blog.torproject.org/blog/tor-heart-apt-transport-tor-and-debian-onions[/ref]

  • The user cannot be uniquely targeted for malicious updates (an adversary is forced to attack everyone requesting the update).
  • The package repository, or observers watching it, can’t track what programs are installed.
  • The ISP cannot easily learn what packages are fetched.
  • End-to-end authentication and encryption provides protection against man-in-the-middle attacks e.g. version downgrade attacks.

While Qubes and Whonix maintain both v2 and v3 onion addresses, users are strongly encouraged to enforce v3 onion connections. This allows users to benefit from the many improvements over the v2 legacy system[ref][NextGenOnions · Wiki · Legacy / Trac · GitLab],aka prop224[/ref] [footnote]Tor v3.2 or higher must be running in Whonix-Gateway (sys-whonix).[/footnote]

Qubes Packages

The following commands must be run in dom0 to configure TemplateVMs to use Qubes’ Tor onion service repositories. [ref]The cat commands are optional and for confirmation only.[/ref]

The downside of this approach is that repository definitions are managed by a Qubes package, meaning manual updates are needed if the the definitions change in the future.

Users that are currently forcing v2 onion connections can update to v3 connections by replacing all instances of the http/URI address (qubes-os.org) below with qubesos4rrrrz6n4.onion


In dom0, run.

sudo sed -i 's/yum.qubes-os.org/yum.sik5nlgfc5qylnnsr57qrbm64zbdx6t4lreyhpon3ychmxmiem7tioad.onion /' /etc/yum.repos.d/qubes-dom0.repo && cat /etc/yum.repos.d/qubes-dom0.repo

sudo sed -i 's/yum.qubes-os.org/yum.sik5nlgfc5qylnnsr57qrbm64zbdx6t4lreyhpon3ychmxmiem7tioad.onion /' /etc/yum.repos.d/qubes-templates.repo && cat /etc/yum.repos.d/qubes-templates.repo

Fedora Template

In dom0, run.

qvm-run -a --nogui -p -u root <your_fedora_template> 'sed -i "s/yum.qubes-os.org/yum.sik5nlgfc5qylnnsr57qrbm64zbdx6t4lreyhpon3ychmxmiem7tioad.onion/" /etc/yum.repos.d/qubes-r* && cat /etc/yum.repos.d/qubes-r*'

Debian and Whonix Templates

In dom0, run.

qvm-run -a --nogui -p -u root <your_debian_template> 'sed -i "s/deb.qubes-os.org/deb.sik5nlgfc5qylnnsr57qrbm64zbdx6t4lreyhpon3ychmxmiem7tioad.onion/" /etc/apt/sources.list.d/qubes-r* && cat /etc/apt/sources.list.d/qubes-r*'

Whonix and Debian Packages

Tip: Whonix 14 will prefer v3 Tor onion services (.onion repositories) by default, even when adding third-party resources.

Until Whonix 14 is released, users may consider manually editing their sources.list to point to the Whonix and Debian .onion mirrors in order to install or update more securely.

The whonix.list and debian.list files in the /etc/apt/sources.list.d directory should be changed in both the Whonix-Workstation and Whonix-Gateway. Qubes-Whonix users note: Complete these steps in the whonix-gw and whonix-ws TemplateVMs.

1. Edit sources.list

In the Whonix-Gateway, edit the debian.list file using an editor with root rights.

If you are using a graphical Whonix or Qubes-Whonix, run.

kdesudo kwrite /etc/apt/sources.list.d/debian.list

If you are using a terminal-only Whonix, run.

sudo nano /etc/apt/sources.list.d/debian.list

2. Reference the Onionized Debian Repositories

Cut and paste the following .onion mirrors and comment out (#) the corresponding http repositories.

#deb Index of /debian jessie main contrib non-free
deb http://vwakviie2ienjx6t.onion/debian jessie main contrib non-free

#deb http://security.debian.org jessie/updates main contrib non-free
deb http://sgvtcaew4bxjd7ln.onion jessie/updates main contrib non-free

#Optional Backports
#deb Index of /debian jessie-backports main contrib non-free
deb http://vwakviie2ienjx6t.onion/debian jessie-backports main contrib non-free

Save and exit.

3. Reference the Onionized Whonix APT Repository

Tip: Whonix users have four package preferences available: stable, stable-proposed-updates, testers and developers. Change the entry below to reflect this preference. [ref]Whonix ™ APT Repository

To use the v3 onion, run. [footnote]Requires Tor v3.2 or above running in Whonix-Gateway (sys-whonix).[/footnote]

sudo whonix_repository --baseuri http://deb.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion --enable --repository stable

4. Confirm the Onionized Repositories are Functional

sudo apt-get update && sudo apt-get dist-upgrade

5. Repeat Steps 1 to 4 for the Whonix-Workstation

Tip: Qubes users can repeat these steps in the Debian TemplateVM to onionize future installations and updates.

6. Optional: Onionize Tor Project Updates

Only complete this step if the Tor versions from The Tor Project repository are being used. The Tor Project deb apt signing key must be added first (see the link above), or the user will receive error messages when completing these steps.

The following commands are run in either the Whonix-Gateway or whonix-gw TemplateVM (Qubes-Whonix-R3.2 ).

Qubes-R-4.0 only! Since TemplateVMs are non-network connected by default,[ref]https://github.com/QubesOS/qubes-issues/issues/1854[/ref] any attempt to download the apt key from whonix-gw will fail. To work around this issue users can fetch the Tor apt singing key from a (networked) anon-whonix AppVM. Then copy the signing key over to whonix-gw in a text file.

To add the Tor Project deb apt signing key, run. (In anon-whonix konsole for Qubes-R4.0)

Note: Whonix 14 users must replace the keyserver address keys.gnupg.net with .onion address jirk5u4osbsr34t5.onion

sudo apt-key adv --keyserver keys.gnupg.net --recv-keys A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89

To display the keys fingerprint, run. (In anon-whonix for Qubes-R4.0)

sudo apt-key adv --fingerprint A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89

Compare the fingerprint displayed in terminal with the one listed on this website How can we help? | Tor Project | Support

(Qubes-R4.0 only!) In anon-whonix, copy the Tor singing key to a new text file named tor.key.

sudo apt-key export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 > /tmp/tor.key

(Qubes-R4.0 only!) In anon-whonix, copy the Tor singing key text file over to whonix-gw, run.

Note: If users encounter the following error it can be safely ignored.

qfile-agent: Fatal error: stat whonix-gw-version (error type: No such file or directory)

qvm-copy /tmp/tor.key whonix-gw

(Qubes-R4.0 only!) In whonix-gw, add the Tor signing key to the list of trusted keys.

sudo apt-key add ~/QubesIncoming/anon-whonix/tor.key

To onionize Tor Project updates first create a torproject.list file using an editor with root rights.

If you are using a graphical Whonix or Qubes-Whonix, run.

kdesudo kwrite /etc/apt/sources.list.d/torproject.list

If you are using a terminal-only Whonix, run.

sudo nano /etc/apt/sources.list.d/torproject.list

Next, cut and paste the following text and comment out (#) the corresponding http repository.

#Tor Project Mirror
#deb Index of /torproject.org jessie main
deb http://sdscoq7snqtznauu.onion/torproject.org jessie main

Save and exit.

@torjunkie As requested (can’t find the post from earlier), I tested Whonix 14 Sandboxed Tor Browser DispVM. Im aware Tor Project has officially abandoned its development. However wanted to let you know:

  • everything worked OK (now moot)

  • a new Child Ticket was created to Remove Tor Browser Sandbox from the Download Page.

    This will effectively kill sandboxed? Should be remove from wiki?