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?
- 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)
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.
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.
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)
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.
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
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.
- 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.
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.
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
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).
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.
Comparison with Others -> Fixed.
(piece of cake, only 215 footnotes there…)
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 ->