Does this still apply…?
Due to a bug in Tor Browser, [1] extra steps are required to use proxies.
This…?
Note: This action will break both the Stream Isolation for Tor Browser and Tor Browser’s tab isolation by socks user name. This worsens the web fingerprint and causes the user to be pseudonymous, rather than anonymous. To mitigate these risks, consider using More than one Tor Browser in Whonix, or better yet, Multiple Whonix-Workstations.
So the fact that we allow other proxies at all would alter the fingerprint. Stream isolation isn’t effective because all connections are headed to the same proxy IP and so use the same circuit.
The part about SOCKS proxies isn’t relevant since we don’t endorse them anyhow.
Based on:
https://sks-keyservers.net/overview-of-pools.php#pool_tor
Tor hidden service
An experimental Tor OnionBalance hidden service is running as hkp://jirk5u4osbsr34t5.onion consisting of the servers marked with Tor support in the status list as backend.
And TorBirdy also using it:
Use the recommended proxy settings for TorBirdy (Tor)
When this option is selected, TorBirdy will change the proxy settings of Thunderbird to configure it to use the Tor network. The settings this options changes are:
SOCKS host: 127.0.0.1 SOCKS port: 9150 Keyserver: hkp://jirk5u4osbsr34t5.onionThis is the default option when TorBirdy is installed.
We should probably point any wiki keyserver steps (i.e. key search and uploading keys) to default to the hkp://jirk5u4osbsr34t5.onion instead?
Hmm looks like we should put this straight into the wiki somewhere appropriate, since we don’t have proper instructions right now on doing this procedure properly? (And will apply somewhat to future versions of Qubes-Whonix).
Manually install Whonix 14 templates
sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable qubes-core-admin-addon-whonix
sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable qubes-template-whonix-gw-14
qvm-create sys-whonix-14 --class AppVM --template whonix-gw-14 --label black
qvm-prefs sys-whonix-14 provides_network True
qvm-tags whonix-gw-14 a whonix-updatevmsudo qubes-dom0-update --enablerepo=qubes-dom0-unstable qubes-template-whonix-ws-14
qvm-features whonix-ws-14 whonix-ws 1
qvm-create whonix-ws-dvm-14 --class AppVM --template whonix-ws-14 --label green
qvm-features whonix-ws-dvm-14 appmenus-dispvm 1
qvm-prefs whonix-ws-dvm-14 template_for_dispvms true
qvm-prefs whonix-ws-dvm-14 netvm sys-whonix-14
qvm-prefs whonix-ws-dvm-14 default_dispvm whonix-ws-dvm-14
qvm-tags whonix-ws-14 a whonix-updatevmTo use the new sys-whonix-14 for your UpdateVM, perform the following steps:
qubes-prefs updatevm sys-whonix-14
Then, edit /etc/qubes-rpc/policy/qubes.UpdatesProxy and modify the top lines:
$type:TemplateVM $default allow,target=sys-whonix
$tag:whonix-updatevm $default allow,target=sys-whonixto become:
$type:TemplateVM $default allow,target=sys-whonix-14
$tag:whonix-updatevm $default allow,target=sys-whonix-14
Done! Please let me know if any changes need to be made. Maybe a little to long?
@torjunkie Since most if not all of my wiki contribs require edits. Would it make more sense for you to make edits in place i.e just make edits to my post? I don’t mind and this would cut down on (sometimes large) semi-duplicate posts. Plus the edit history is still available.
BTW thanks for helping out with my edit backlog 
Libre Software Development VS. Development in a Company
The method used to development of
Libre/freesoftware can vary greatly between projects and factors such as software type and design goals of the project play an important roll when deciding which methodology to use. When developing proprietary software a more tradition method is typically used which used a centralized approach. In this model all aspects of the project are tightly managed and participants are given clearly defined rolls with in the project. Only a select few developers have access to the source code and its not uncommon to have many participants dedicated to core development, project management, implementation and bug tracking.In stark contrast is the
Libre[1] model which uses a decentralized style encouraging the users themselves to become involved in the development of the project. In this model participants are loosely managed and the source code is publicly available. This model solves many of the issues faced with closed-source development by integrating users into the developmental process. SinceLibreusers have the freedom to use and improve the software any way they like[ref]Free software - Wikipedia, they make ideal candidates to also assume the role of a “developer” of the project.[blockquote]The terms user and developer here refer to someone’s relationship to the open source software project in question, not to her identity in the world at large.
For example, if the open source project is a Javascript library intended for use in web development, and someone is using the library as part of her work building web sites, then she is a “user” of the library (even though professionally her title might be “software developer”). But if she starts contributing bugfixes and enhancements back upstream[2] – that is, back into the project – then, to the extent that she becomes involved in the project’s maintenance, she is also a “developer” of the project[ref]https://producingoss.com/en/getting-started.html[ref] [end/blockquote].
The relationship between users and developers can be very porous: every user is a potential developer. This principle is apparent in the Libre developmental model.
Users should be treated as co-developers - Users are treated like co-developers. As such they should have access to the source code of the software. Furthermore, users are encouraged to contribute additional code , bug reports, bug patches etc. By having more co-developers, the rate in which bugs are found and fixed increases substantially. Note that some users have advanced programming skills, and furthermore, each user’s machine provides an additional testing environment. This new testing environment offers that ability to find and fix a new bug. This in turn allows the software to evolve at a quicker rate. This concept is termed as Linus’ Law[3] which states:
[blockquote]“Given enough eyeballs all bugs are shallow.”[/blockquote]
Early releases - Since many volunteers are attracted to help develop the software based on the early release. This first version should be released as early as possible. This increases the chances of finding co-developers.
At least two versions of software should be available
- Stable version - This version has fewer features than the developmental version but has been thoroughly tested and most identified bugs have been fixed.
- Developmental version - For users that desire the use of the latest features not found in the stable version. Since this version has not been thoroughly tested, users must being willing to accept the risk of using a version that does not yet have all bugs patched. users can act as co-developers, providing bug reports and submitting bug patches for the developmental version.
Use a highly modular structure - The structure of the software should be modular allowing for parallel development on independent interchangeable components.
Frequent code integration - Code changes should be merged into a shared code base as often as possible to avoid the overhead of fixing a large number of bugs at the end of the project life cycle. Some open source projects have nightly builds[4] where integration is done automatically on a daily basis.
Dynamic decisions making structure - There is a need for a decision making structure, whether formal or informal, that makes strategic decisions depending on changing user requirements and other factors.
Development in a Company
DevelopingLibre/freesoftware can not not be accomplished using a more traditional method. With a decentralize approach participants have much more flexibility in the developmental process which allows the software to be developed according to technical guidelines. Although this allows for companies to adapt according to different developmental needs. There are elements that can influence the overall outcome of software.Third Party Software
For companies that only use software that is developed from within there company, the design goals which users expect can be met with less difficulty. However, this may not be the case for companies that also use software developed by other
Libre/freecompanies. This software is developed according to the design goals of the third party project which may run counter to that of the company that uses the software. This applies not only to packages integrated into the software but also to the standalone software that may be used to support development. Changes to third party software can be time consuming and costly and smaller companies may not not have the necessary resources.This simple illustration shows third party software used by Whonix. Note that some of the third party software also uses packages from other 3rd party project. Many of these companies do not share the same design goals as Whonix (advanced security and anonymity).
Firefox Web Browser --- Tor Browser --- --- Phabricator (bug/issue tracker) \ / Whonix ---> Infrastructure --- MediaWiki / \ Debian OS --- --- Discource (forum software) / \ Many software packages --- --- Google search engineCompany Size
The size of the company has a significant impact on development. AlthoughLibrecompanies use the same methodology in development, the developmental practices used to achieve these goals is difference across companies of different sizes.Large Companies
Many large companies employ many full-time employees and may receive contributions from hundreds[ref]The Linux kernel has about 200-250 companies on average per release contributing patches[/ref] of companies which use and depend upon the software, as well as hobbyist and research developers. Many of these companies also integrate third party packages into their software. If design changes are needed in this software the resources are available to either assign an employee to develop, test and submit a patch, or if necessary sponsor the third party company to make the desired changes.
Small Companies
Since small companies have limited resources they do not have full-time employees akin to larger companies (if they have them at all). Its not uncommon for these companies to have a 1 or possibly 2 core developers along with a small number of community members that make contributions towards development. Quite often, due to limited resources these companies must remain focused on core development which leaves less time to develop new features. This in turn prevents developers from presenting users with a unified experience[11] when using their software.
Making Changes to a Third Party Software
Its common for companies to use third party packages in their infrastructure and also integrated into their software. Although they may provide many benefits to the company, they are not always developed with identical design goals. This can lead to software not functioning as a user expects or may even break other packages. There are several options if changes are wanted in the third party software all of which require time and/or resources
Polity ask the company to make the changes
Submit a Patch that makes sense from their point of view
Fork the software and add your own patches
Use software from an alternate third party project
The methods used to change software is identical whether the request is from a large company or collaborator from a small community. When requesting changes try look at the software from the perspective of the third party project. The developers are more likely to accept the changes if they also benefit the design goals of the project. If significant workload is added with little benefit to the project, the changes would likely be rejected. Many project have instructions specifying how to submit patches on their web site. Whonix Patches Welcome[12]
The last option is to fork the software and add your own patch. Since maintaining an additional software package could increase the workload substantially. Forking software is usually not an option for small companies with little resources. The better option would be to submit a patch so all users of the software would benefit, not just users of software from one company.
Links
[2] Upstream (software development) - Wikipedia
[3] https://en.wikipedia.org/wiki/Linus's_Law
[6] Internet forum - Wikipedia
[7] Git - Wikipedia
My plan is to complete:
to use
curlin Whonix users should usecurl.anondist-orig
Then start working on:
Qubes R4 adjustments for DisposableVMs
It looks as though “Libre Software Development VS. Development in a Company” chapter has an identity crisis. The first section is “This is the model, this is what you need to develop Libre” when is should be “LIbre model co-developer concept”.
Second section “Development in a Company” needs to be shortened.
I’ll have the edits completed later on today.
Not sure where we discussed this. Just to make sure: This is not a wiki wide thing. Only when they want curl without stream isolation.
“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"
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:
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: Reasons for Freedom Software / Open Source)
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.
However…
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.
Yes.
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
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.
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.
→ 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
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.