Long Wiki Edits Thread

Website
61

Qubes AppArmor Test - Using the Scientific Method:

TemplateVMs

1) Start with whonix TemplateVMs clones (whonw-ws-clone-1; whonix-gw-clone-1) with default kernelopts settings

2) Check current kernel parameters

dom0:

qvm-prefs -l whonix-gw-clone-1 kernelopts

qvm-prefs -l whonix-ws-clone-1 kernelopts

Output:

nopat

AppVMs

3) Create AppVMs based on default TemplateVMs above

Note: Since this will be the default situation for most users who install Whonix via the Qubes installer i.e. AppVMs with default settings.

That is, now having:

  • sys-whonix-clone-1
  • anon-whonix-clone-1

4) Start AppVMs above and check AppArmor is not active:

As expected:

sudo aa-status --enabled ; echo $?

Shows:

3

That is, not ‘0’ (as when AppArmor is active).

TemplateVMs again

5) Change kernelopts settings in the TemplateVMs to enable AppArmor

dom0:

qvm-prefs -s whonix-gw-clone-1 kernelopts “nopat apparmor=1 security=apparmor”

qvm-prefs -s whonix-ws-clone-1 kernelopts “nopat apparmor=1 security=apparmor”

6) List the kernel parameters again to check AppArmor is now active for TemplateVMs

dom0:

qvm-prefs -l whonix-gw-clone-1 kernelopts

qvm-prefs -l whonix-ws-clone-1 kernelopts

Output (as expected):

nopat appamor=1 security=apparmor

7) CRITICAL POINT - What do the pre-existing AppVMs say regarding AppArmor status now!?

sudo aa-status --enabled ; echo $?

Output:

0

Conclusions

  • Pre-existing AppVMs inherit kernelopts changes from their parent TemplateVM -> only kernelopts changes in the TemplateVMs are needed
  • AppVMs do NOT need to be recreated to inherit the AppArmor framework i.e. all references to ‘create new AppVMs’ blah blah can be removed (which I’ve done)
  • It doesn’t matter how users came to have their existing Whonix set-up in Qubes (Qubes installer or otherwise), since this wiki entry will give them what they want if they follow the steps
  • torjunkie is an idiot and will go insane if I have to edit this Template again
  • Sometimes it is better to test something quickly and easily, rather than rely on forums, where things get lost in translation

:joy: :sweat_smile: :laughing:

I’ve fixed this entry and am moving on…

Other

1) Just let me know that the suggested Tox changes (further above) are okay and I’ll insert it, since my entry is wrong currently (no “su”; wrong order in installation steps)
2) I’ll test the Whonix wiki bot over the weekend for you to see it’s all working

Cheers

1 Like
62

Great!

Yes, please go ahead with tox.

63

Done. http://kkkkkkkkkk63ava6.onion/wiki/Template:Tox → Fixed.

Re: downloading and importing Whonix-Custom-Workstation (VM Settings Easy Common template), I see on the server that the latest available Whonix version is: 9 for this customized build.

Since we are pushing Whonix 14 in a few months, perhaps I should just mark that part of the template as “deprecated”?

Unless people can somehow install it and do an upgrade bumping Whonix up several versions at once to the current 13 version (which I doubt).

1 Like
64

Some more edits to Template:Tox - Whonix. Please check.

This is expected. Should be explained why it’s not updated.

1 Like
65

Thanks! You’re schooling me on GPG (good to know this stuff).

Tox Template:

  • Added a reference for list of GPG fingerprints used by qTox developers for users to check
  • Removed a few “sudo” references, since everything is run in root
  • Removed ugly bullet point effect from the footnotes
  • Added one footnote re: updating the Tox apt repository to “Stretch” when Whonix gets upgraded
  • Tested these instructions in a TemplateVM, created the AppVM, and ran qTox -> worked perfectly!

Cheers

1 Like
66

re Tox:

I removed the su for becoming root in my previous edit. To be allied with most other places in the wiki where we consistently use sudo. I open to reconsider this. There are some commands that should not be run as root.

  • wget
  • gpg --keyid-format long --with-fingerprint Release.key

(So currently it’s broken since never su nor sudo.)

I don’t know if the rest gets simpler by using su and exit rather than using sudo everywhere. You tell me.

1 Like
67

Right - good point. Tox -> Fixed.

Removed root instruction and changed these things to sudo (since I checked that it’s required permission-wise):

  • copy .gpg pubkey to /etc/apt
  • create a new qtox.list
  • update package lists
  • install qTox

These don’t require sudo permissions (I checked):

  • wget
  • checking gpg fingerprint
  • converting the Tox signing key to a keyring to be used by apt

Contribution Page

I fixed that up. The only bit I didn’t - I think you told me not to before - was this part:

Donations tax-deducible by default are not tax-deductible because Whonix has no legal structure for that. If you would like to make a tax-deducible donation, we can make that work as well, please get in contact.

Unreadable first line and awkward second line. I’d really suggest something like:

The Whonix legal structure does not provide for donations that are normally tax-deductable by default. If you would like to make a tax-deductable donation, please get in contact so we can make that work for you.

Formatting in General

Yes, in the long term (post months of editing wiki pages for basic grammar and readability), there needs to be a conscious effort to standardize formatting across the wiki and improve the overall presentation. I’m trying to do many of these as I go along:

  • Root vs sudo
  • Consistency in the size of text in various areas
  • Creating other templates for commonly used steps
  • Shifting around text that is repeated in multiple areas (the Security Guide, Advanced Security Guide, Computer Security Education and some others are the worst offenders - particularly the beginning chapters of the wiki which need to be merged / deleted)
  • Shifting text around to actually match the level of difficulty for various security guides
  • Rationalizing the overall Table of Contents and the order in which things appear. It’s a dog’s breakfast right now.
  • Use of sub-chapter headings to break up huge blocks of text that are basically unreadable now
  • Consistency in mediawiki heading / sub-heading formatting
  • Consistency in mediawiki forms used e.g. pre vs code and a million others
  • Consistency in the amount of text allocated to its own heading / sub-heading e.g. sometimes three words, sometimes a whole page
  • More appropriate use of paragraphs. It is wildly inconsistent now which affects readability. Sometimes it is one line, sometimes it is a huge block of text
  • Greater use of tables to summarize issues that have a lot of specific points to consider
  • Updated screenshots since many in the wiki are ancient / outdated. Screenshots for many topics would make the wiki much more presentable and improve user understanding of various issues
  • Consistency re: accepted English standards e.g.
    – Capitalization
    – Bullet point style
    – British English vs American English
    – Bold vs italic text vs underlined text etc
    – Colons vs semi-colons (and capitalization following colons; we’re not consistent)
    – Appropriate use of hyphenated text
    – Passive vs active voice in writing style (the active voice is generally better for readability and clarity)
    – Use of pronouns - I / you / your / we / he / she / us /mine etc are generally best avoided. It’s better to use “the” where possible and not possessive pronouns and other forms
    – Removing any slang / common forms of English that pop up here and there
    – Standardization of acronyms (e.g. DispVM vs DisposableVM, and a million others)
    – Avoiding shortened forms of words for clarity e.g. distros vs distributions
    – A shit load of others that I can’t remember right now
1 Like
68

re: https://www.whonix.org/wiki/Template:Donate

Right. The previous sentence was obviously broken. Added your fixed sentence. I don’t know why we used “by default”. Simplified to:

Donations are not tax-dedutable. If you would like to make a tax-deductable donation, please get in contact so we can make that work for you.

What do you think?

Great points!

Right, I guess sudo is easier.

Right, such as for third party repositories, gpg fingerprint verification, signing key adding. As far that is possible. For example it differs gpg key download over clearnet and wget vs https scurl.

I guess CodeSelect everywhere, except for maybe <pre> for cases where it’s just for formatting, not for easy copy and paste.

1 Like
69

Great that we are on the same page.

That donations text looks much better now (your suggestion).

I forgot to add in the grammatical critique:

  • Avoiding run on sentences; and
  • Not overusing brackets “()” in writing. Usually it’s best to reorganize the sentence and write it outside of brackets, or footnote the issue if it is a minor point. Also, it is not normal to start a sentence with bracketed text.

There are others, but I don’t want to go crazy :wink: First things first, let’s finish the template edits - I’ll go back and look over some recent ones you’ve added, then I will methodically go through each wiki page listed in the Table of Contents for general edits.

The finer stuff can come later. But, let me add another link in the forums here for you and others on the team to add re: missing templates required. So far, based on your list:

  • Adding Third-party Repositories
  • GPG Fingerprint Verification
  • Adding Signing Keys
  • Others?
1 Like
70

Are you sure it is better to use

colon

Explanation what to do:

<pre>
actual command
</pre>

vs

dot

Explanation what to do.

<pre>
actual command
</pre>

?

Most guides I saw anywhere are using . rather than :.

71

That’s a good point re: colon & instructions/steps.

I just made that decision on the fly. If it is a full stop/period in most computer tutorials (I’m sure you’ve read a million), then lets note to fix them all back in the ‘finer edits’ Round 2 of the wiki edits. In the meantime, I’ll just use periods instead of colons going forward.

Re - Template: Verifiable Pkgs Introduction

The Debian dpkg bug causing the installed size to be wrong by a factor of 8 has now been resolved. I footnoted that, but noted those steps are still deprecated because it is difficult to implement at this time prior to Debian Stretch etc.

Note, this editing led me to conclude ->

Do we need a Maintainer Required Warning Box template?

I know the status box template already exists, but I keep seeing the manual warning box repeated all throughout the verifiable builds templates I have been editing of late.

So the template could look something like this:

{{mbox
| image = [[File:Ambox_warning_pn.svg.png|40px|alt=verifiable builds warning icon]]
| text =
Warning:

A dedicated [[Contribute#Maintainer|maintainer]] is required.
}}

1 Like
72

Yes, created empty https://www.whonix.org/wiki/Template:Maintainer_Required.

1 Like
73

Template:Verify_the_Whonix_images

Changed the mbox “type =” from “critical” to “content”.

It was coming up with an error before saying “critical” is not an accepted field blah blah and not presenting properly (I think it was also based on a template “Main” that was deleted sometime in the recent past?). I’m sure you can fix it up if it’s something basic.

See mbox types here: Template:Mbox - MediaWiki

Do we need the {{ }} brackets around “Verify the virtual machine images using Linux”? It presents strangely.

Template:Verify_the_virtual_machine_images_using_Linux

There is strange formatting in this template that doesn’t present properly (broken links?) e.g.

({{{file_extension}}})

And

[[{{{download_signature_link}}}|Download Whonix Signature]]

And

{{{signature_notation_gw}}}

Not sure if they’re fixable, so I’ve left them for you to decide.

Template:Donate

Spelling error & and the internet tells me it is “deductible” not “deductable” :slight_smile:

Original:

Donations are not tax-dedutable. If you would like to make a
tax-deductable donation, please get in contact so we can make that work for you.

Change →

Donations are not tax-deductible. If you would like to make a
tax-deductible donation, please get in contact so we can make that work for you.

So, I’ve done one editing round on the 236 templates. But I’ve missed a few earlier on I think e.g. build templates and some others, plus any new ones you’ve added lately.

So, I should probably go back and look through again (quickly) to cover those off and do some finer edits re: colons and a few other things, since that will be quick and easy. Here and there I’ll break up the boredom with general wiki page edits.

Once done, I propose to start editing the wiki entries in order as they appear in the ToC.

1 Like
74

Note in the second round of template edits, I will focus on finer grammatical points already noted above, plus:

  • Double quotation marks in most instances i.e. " " is better than ’ '. The grammar texts note that " " is more common and usually correct in most instances.
  • Use American English i.e. simplified spelling etc.
  • I think we should also standardize file path references in italics consistently e.g. this form:

Open /etc/apt/preferences.d/debian-pinning.pref in an editor with root rights.

There were some other points that I can’t remember right now, but it’ll come to me…

1 Like
75

torjunkie:

Do we need the {{ }} brackets around “Verify the virtual machine images using Linux”? It presents strangely.

Yes. Please fix. I think the intention back then was to make that link
going to either VirtualBox or KVM verification instructions depending
from where the template is being referenced, i.e. from VirtualBox or KVM
wiki page. Please fix the easy or “perfect” way.

76

1) Re: above → Done.

(Additional edits are looking much better without pronouns and better stylistic formatting as we agreed further above.)

2) Also, shouldn’t the license page be:

Copyright (C) 2012 - 2017

?

If not, at a minimum there should be an additional space after the hyphen.

3) Template:FoxyProxy looks well out of date and messy.

It mentions 6 steps, but there are only 3 steps in there.

Do you want me to test FoxyProxy with Tor Browser 7.0a2 using Goldstein’s method of disabling sig verification and fix up the entry?

I think also we can lose all references to the “hardened” Tor Browser since that will die very shortly.

4) Next Tor Browser release.

I understand that the next release (?) will have FF ESR 52 applied to the Alpha series of Tor Browser (but not the normal release series). So, with e10s applied and a lot of changes, this will no doubt screw with Whonix settings in some way, shape or form.

Have you tried the nighties from The Tor Project to check general compatibility?

https://people.torproject.org/~linus/builds/

I’m happy to also run a test in Whonix 13 if you like. The chances of this working like a dream I think are remote (see Tor Trac issues around ESR 52 - many, many bugs, patches, fixups and strange behaviours).

5) I realize bullet points are a grammatical nightmare of their own.

Technically the rules are:

a) Bullet points don’t need the first letter of the first word to be capitalized unless the bullet points comprise a full sentence e.g.

These are okay:

  • multiple Whonix-Workstation TemplateVMs

Or

  • Always check that the GPG timestamp makes sense.

b) But technically the following are NOT okay:

  • Multiple Whonix-Workstation TemplateVMs

Or

  • always check that the GPG timstamp makes sense

Or

  • Always check that the GPG timestamp makes sense

c) The other accepted method is having bullet points finish with a semi-colon, a period for the last bullet point, and using a conjunction on the second-last bullet point e.g. “and” “or” “and/or”. This is the British English style, applies in certain industry standards etc. For example, these are okay:

  • time-stamps;
  • signature verification; and
  • checking the signing key.

Or

  • Make sure you download the Whonix-Workstation and Whonix-Gateway virtual images; and
  • Verify the images after downloading them.

d) All of these same rules apply to numbered lists

e) Many websites ignore these rules e.g. the Qubes website that capitalizes the first word and doesn’t end the bullet points in a period. Probably because it looks better.

I think we should adopt the most commonly accepted method i.e. part a). Right now we have a mix of all of the above throughout the entire wiki…

1 Like
77
  1. If it’s copyright under my name, then yes, can be updated.

Yes, please fix.

  1. Bigger changes to Template:FoxyProxy, i.e. method changes should be discussed in https://forums.whonix.org/t/new-version-of-tbb-no-longer-accepts-foxyproxy-plugin. Yes, please feel encouraged to work on that one.

As for disabling signature verification, we need to make sure what we are actually disabling. Installing foxyproxy from Debian repository (when apt-get already done signature verification) and then just force adding the add-on to Tor Browser would be fine. However, if we disable signature verification which then would result in no longer checking any signatures for addons installed from addons.mozilla.org, that’s not a great. Doing that temporary would be okay (if the add-on stays functional after installation).

Also GK (TBB dev) said it’s working for him.
https://lists.torproject.org/pipermail/tbb-dev/2017-February/000471.html

So this could require posting on tbb-dev again with a clear concise description of steps done, expected results, actual results. Should probably draft it and write then.

In that thread, talking past each other is so simple…

  • this workaround doesn't work with the latest addon-manager version from Mozilla
  • Not sure what you mean with "latest addon-manager version from Mozilla"

…so the text must be as explicit as possible, reusing exact terms, describing actions step by step (i.e. Tor Browser → Tools → Add-ons) and whatnot.

Well, as long as it exists it’s good to have a small chapter about it somewhere.

  1. By all means, please test.

  2. Yes, please fix.

78

Template:Build Documentation apt-cache: Difference between revisions - Whonix has a mistake. When “can be used” is written anywhere, I am quite certain, the meaning really is “it’s a possibility, you could do that”. Writing “is used” is certainly wrong. That sentence just explains a possible setup one could do.

79

On Template:Control Port Filter Python Profile Add - Whonix, should we describe what the mkdir and cp commands are actually doing?

80

Template:Design Introduction - Whonix is nice.

  • once done, deserves an extra thread
  • I only disagree with using <pre> for quotes. The issue with pre tags is, that it’s more suited for code that should be unmodified at all cost. pre does not do line breaks. It results in a page that must be scrolled horizontally. <blockquote> is for quotes. And if we don’t like that, we still need an alternative formatting for quotes.

Minor:

  • should be moved elsewhere, since where the template is used it makes little sense - Login required - Whonix
  • needs a better page name
1 Like