fix typos

common-tasks/backup-restore.md

@@ -11,7 +11,7 @@ redirect_from:
 Qubes Backup, Restoration, and Migration
 ========================================
 
-**Caution:** The Qubes backup system currently relies on a [weak key derivation scheme](https://github.com/QubesOS/qubes-issues/issues/971). It is *strongly recommended* that users select a *high-entropy* passphrase for use with with Qubes backups.
+**Caution:** The Qubes backup system currently relies on a [weak key derivation scheme](https://github.com/QubesOS/qubes-issues/issues/971). It is *strongly recommended* that users select a *high-entropy* passphrase for use with Qubes backups.
 
  * [Creating a Backup](#creating-a-backup)
  * [Restoring from a Backup](#restoring-from-a-backup)

common-tasks/software-update-vm.md

@@ -56,7 +56,7 @@ As long as template's compromise is considered, it doesn't really matter whether
 
 -   But why trusting Fedora?
 
-Because we chose to use Fedora as a vendor for the Qubes OS foundation (e.g. for Dom0 packages and for AppVM packages). We also chose to trust several other vendors, such as Xen.org, kernel.org, and a few others whose software we use in Dom0. We had to trust *somebody* as we are unable to write all the software from scratch ourselves. But there is a big difference in trusting all Fedora packages to be non-malicious (in terms of installation scripts) vs. trusting all those packages are non-buggy and non-epxloitable. We certainly do not assume the latter.
+Because we chose to use Fedora as a vendor for the Qubes OS foundation (e.g. for Dom0 packages and for AppVM packages). We also chose to trust several other vendors, such as Xen.org, kernel.org, and a few others whose software we use in Dom0. We had to trust *somebody* as we are unable to write all the software from scratch ourselves. But there is a big difference in trusting all Fedora packages to be non-malicious (in terms of installation scripts) vs. trusting all those packages are non-buggy and non-exploitable. We certainly do not assume the latter.
 
 -   So, are the template VMs as trusted as Dom0?
 

developers/fundamentals/gui.md

@@ -75,7 +75,7 @@ Certainly, it would be insecure to allow AppVM to read/write clipboard of other
 
 -   there is a "qubes clipboard" in dom0 - its contents is stored in a regular file in dom0.
 -   if user wants to copy local AppVM clipboard to qubes clipboard, she must focus on any window belonging to this AppVM, and press **Ctrl-Shift-C**. This combination is trapped by *qubes-guid*, and `CLIPBOARD_REQ` message is sent to AppVM. *qubes-gui* responds with *CLIPBOARD_DATA* message followed by clipboard contents.
--   user focuses on other AppVM window, presses **Ctrl-Shift-V**. This combination is trapped by *qubes-guid*, and `CLIPBOARD_DATA` message followed by qubes clipboard contents is sent to AppVM; *qubes_gui* copies data to the the local clipboard, and then user can paste its contents to local applications normally.
+-   user focuses on other AppVM window, presses **Ctrl-Shift-V**. This combination is trapped by *qubes-guid*, and `CLIPBOARD_DATA` message followed by qubes clipboard contents is sent to AppVM; *qubes_gui* copies data to the local clipboard, and then user can paste its contents to local applications normally.
 
 This way, user can quickly copy clipboards between AppVMs. This action is fully controlled by the user, it cannot be triggered/forced by any AppVM.
 

developers/fundamentals/template-implementation.md

@@ -87,7 +87,7 @@ Steps performed by **qvm-revert-template-changes**:
 3.  Replace *snapshot* device-mapper target with *snapshot-merge*, other parameters (chunk size etc) remains untouched. Now kernel starts merging changes stored in *root-cow.img.old* into *root.img*. d-m device can be used normally (if needed).
 4.  Waits for merge completed: *dmsetup status* shows used snapshot blocks – it should be equal to metadata size when completed.
 5.  Replace *snapshot-merge* d-m target back to *snapshot*.
-6.  Cleanup snapshot device (if nobody uses it it the moment).
+6.  Cleanup snapshot device (if nobody uses it at the moment).
 7.  Move *root-cow.img.old* to *root-cow.img* (overriding existing file).
 
 Snapshot device in AppVM

developers/services/dvm-impl.md

@@ -30,7 +30,7 @@ Preparing a savefile is done by */usr/lib/qubes/qubes\_prepare\_saved\_domain.sh
 6.  when `qubes_used_mem` key appears, the domain memory is reduced to this amount, to make the savefile smaller.
 7.  APPVM private image is detached
 8.  the domain is saved via *xl save*
-9.  the COW file volatile.img (cow for for root fs and swap) is packed to `saved_cows.tar` archive
+9.  the COW file volatile.img (cow for root fs and swap) is packed to `saved_cows.tar` archive
 
 *qubes\_prepare\_saved\_domain.sh* script is somehow lowlevel. It is usually called by *qvm-create-default-dvm* script, that takes care of creating a special AppVM (named template\_name-dvm) to be passed to *qubes\_prepare\_saved\_domain.sh*, as well as copying the savefile to /dev/shm (the latter action is not done if the `/var/lib/qubes/dvmdata/dont_use_shm` file exists).
 
@@ -53,4 +53,4 @@ Validating the DisposableVM savefile
 
 DisposableVM savefile contains references to template rootfs and to COW files. The COW files are restored before each DisposableVM start, so they cannot change. On the other hand, if templateVM is started, the template rootfs will change, and it may not be coherent with the COW files.
 
-Therefore, the check for template rootfs modification time being older than DisposableVM savefile modification time is required. It is done in *qfilexchgd* daemon, just before restoring DisposableVM. If necassary, an attempt is made to recreate the DisposableVM savefile, using the last template used (or default template, if run for the first time) and the default prerun script, residing at */var/lib/qubes/vm-templates/templatename/dispvm\_prerun.sh*. Unfortunately, the prerun script takes a lot of time to execute - therefore, after template rootfs modification, the next DisposableVM creation can be longer by about 2.5 minutes.
+Therefore, the check for template rootfs modification time being older than DisposableVM savefile modification time is required. It is done in *qfilexchgd* daemon, just before restoring DisposableVM. If necessary, an attempt is made to recreate the DisposableVM savefile, using the last template used (or default template, if run for the first time) and the default prerun script, residing at */var/lib/qubes/vm-templates/templatename/dispvm\_prerun.sh*. Unfortunately, the prerun script takes a lot of time to execute - therefore, after template rootfs modification, the next DisposableVM creation can be longer by about 2.5 minutes.

developers/services/qmemman.md

@@ -70,7 +70,7 @@ Additionally, the balance algorithm is tuned so that XEN\_FREE\_MEM\_LEFT (50MB)
 Whenever *qmemman* is asked to return X megabytes of memory to Xen free pool, the following algorithm (*qmemman\_algo.balloon*) is executed:
 
 1.  find all domains ("donors") whose actual memory is greater than its `prefmem`
-2.  calculate how much memory can be reclaimed by shrinking donors to their `prefmem`. If is is less than X, return error.
+2.  calculate how much memory can be reclaimed by shrinking donors to their `prefmem`. If it is less than X, return error.
 3.  shrink donors, proportionally to their `prefmem`, so that X MB should become free
 4.  wait BALOON\_DELAY (0.1s)
 5.  if some domain have not given back any memory, remove it from the donors list, and go to step 2, unless we already did MAX\_TRIES (20) iterations (then return error).

developers/services/qrexec2.md

@@ -313,7 +313,7 @@ steps are taken:
  * `qrexec-daemon` executes `qrexec-policy`, passing source vmname, target
  vmname, rpc action, and CID as cmdline arguments
  * `qrexec-policy` evaluates the policy file. If successful, creates a pair of
- `qrexec-client` processes, whose stdin/stdout are cross-connencted.
+ `qrexec-client` processes, whose stdin/stdout are cross-connected.
    * The first `qrexec-client` connects to the src VM, using the `-c ClientID`
    parameter, which results in not creating a new process, but connecting to
    the existing process file descriptors (these are the fds of unix socket

installing/live-usb.md

@@ -20,7 +20,7 @@ We have faced several challenges when making this Live USB edition of Qubes OS,
 which traditional Linux distros don't have to bother with:
 
 1. We needed to ensure Xen is properly started when booting the stick. In fact
-   we still don't support UEFI boot for the sitck for this reason, even though
+   we still don't support UEFI boot for the stick for this reason, even though
    the Fedora liveusb creator we used does support it. Only legacy boot for this
    version, sorry.
 2. We discovered that the Fedora liveusb-create does *not* verify signatures on

installing/multiboot.md

@@ -21,7 +21,7 @@ Read the [guidelines](/doc/security-guidelines) carefully.
 One problem is that when you dual or multiboot, even if you are using
 encryption on your Qubes installation, /boot is still unprotected and
 could be maliciously modified by the other OS, possibly leading to Qubes
-itself being maliciously modifed.
+itself being maliciously modified.
 
 The other problem is firmware security - for example the other system
 could infect BIOS firmware, which might enable compromise or spying on
@@ -177,8 +177,8 @@ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
 Troubleshooting
 ----------------------
 
-If you install Qubes without making any backups beforehand, dont worry.  
-If you didnt overwrite the original partitions, then it is usually
+If you install Qubes without making any backups beforehand, don't worry.
+If you didn't overwrite the original partitions, then it is usually
 possible to recover your old systems relatively easily, as described above.
 
 If you decided to use a shared /boot and *dont* have backups of your previous

managing-os/templates/archlinux.md

@@ -106,7 +106,7 @@ Main maintainer of this template is [Olivier Médoc](mailto:o_medoc@yahoo.fr).
 <br>
 <br>
 
-*    You will now have the Qubes Builder System enviornment installed in the directory below:
+*    You will now have the Qubes Builder System environment installed in the directory below:
 
     *   **/home/user/qubes-builder**
 <br>
@@ -115,7 +115,7 @@ Main maintainer of this template is [Olivier Médoc](mailto:o_medoc@yahoo.fr).
 
 ##### **5:   Configuring setup script to create builder.conf file:** #####
 
-*   You will be creating the builder.conf file which tells where and what to use.   The most automated, and in in this case the easiest, way to create this is to use the script that is provided in Qubes Builder.  Its named '**setup**'.  Before running the script you need to edit one file it uses.  
+*   You will be creating the builder.conf file which tells where and what to use.   The most automated, and in this case the easiest, way to create this is to use the script that is provided in Qubes Builder.  Its named '**setup**'.  Before running the script you need to edit one file it uses.
    
     *In the future this should not be needed once a change is made to the 'setup' script.*
 
@@ -363,11 +363,11 @@ Main maintainer of this template is [Olivier Médoc](mailto:o_medoc@yahoo.fr).
 
 One last thing to setup to have a "PROPERLY" functioning archlinux template.
 
-Archlinux package manager Pacman is  a fine package mangers execpt that we could not find a way to configure it to use the Qubes Update Proxy Service (QUPS) that would compliy with Qubes QUPS usage policy.  
+Archlinux package manager Pacman is  a fine package mangers except that we could not find a way to configure it to use the Qubes Update Proxy Service (QUPS) that would comply with Qubes QUPS usage policy.
 
 *If someone does find a way please post to the Qubes-Users or Devel google groups mailing list.*
 
-Powerpill is a full Pacman wrapper that not only give easy proxy configuration but futher offers numerous other advantages.   
+Powerpill is a full Pacman wrapper that not only give easy proxy configuration but further offers numerous other advantages.
 
 Please check out:
 
@@ -376,7 +376,7 @@ Please check out:
 [XYNE's (dev) Powerpill](http://xyne.archlinux.ca/projects/powerpill/)
 
 
-**Important Note:** Until Powerpill is configured you will have to open network access to the template to get the intial packages etc downloaded.  You can use the "allow full access for" a given time period in the FW settings of the template in the VMM or open up the various services thru the same window.  Remember to change it back if you choose the later route.  Actions needing network access will be noted with (needs network access)
+**Important Note:** Until Powerpill is configured you will have to open network access to the template to get the initial packages etc downloaded.  You can use the "allow full access for" a given time period in the FW settings of the template in the VMM or open up the various services thru the same window.  Remember to change it back if you choose the later route.  Actions needing network access will be noted with (needs network access)
 
 <br>
 <br>
@@ -389,7 +389,7 @@ Please check out:
 
 *   **$ sudo nano -w /etc/pacman.conf**
         
-* Below is the output of a correct pacman.conf file  Make the changes so your file matches this one or rename the orginal and create a new one and copy and paste this text into it.  Text should be justifed left in the file.  The changes from your default are to make gpg sig signing mandatory for packages but not required for DBs for the archlinux repos.  Also to add the repo (at the end) for the Powerpill package.
+* Below is the output of a correct pacman.conf file  Make the changes so your file matches this one or rename the original and create a new one and copy and paste this text into it.  Text should be justified left in the file.  The changes from your default are to make gpg sig signing mandatory for packages but not required for DBs for the archlinux repos.  Also to add the repo (at the end) for the Powerpill package.
 
 
 <br>
@@ -542,7 +542,7 @@ Please check out:
 
     *   Confirm keys with those at [Archlinux Master Keys](https://www.archlinux.org/master-keys/)
 
-    *   For more information on Pacman key sigining: [Pacman Package Key Signing](https://wiki.archlinux.org/index.php/Pacman/Package_signing)
+    *   For more information on Pacman key signing: [Pacman Package Key Signing](https://wiki.archlinux.org/index.php/Pacman/Package_signing)
 
 <br>
 <br>
@@ -579,7 +579,7 @@ Note: For info on Reflector and its configs: [Reflector](https://wiki.archlinux.
 
 *Note: Look at the Reflector page to decide what filter and argument string you wish to run. Below is a default string that will work for most all to setup a working basic mirrorlist.  
 
-*Look to Reflector pages or --help for more info on arug and filters.*
+*Look to Reflector pages or --help for more info on args and filters.*
 
 *   **$ sudo reflector --verbose -l 5 --sort rate --save /etc/pacman.d/mirrorlist**
 

privacy/torvm.md

@@ -189,7 +189,7 @@ access with different stream isolation settings:
 * Port 9050 - Isolates by SOCKS Auth and client address only  
               Each AppVM gets its own circuit, and each app using a unique SOCKS
               user/pass gets its own circuit
-* Port 9049 - Isolates client + estination port, address, and by SOCKS Auth
+* Port 9049 - Isolates client + destination port, address, and by SOCKS Auth
               Same as default settings listed above, but additionally traffic
               is isolated based on destination port and destination address.
 

reference/vm-tools/qvm-run.md

@@ -22,7 +22,7 @@ Date
 SYNOPSIS
 --------
 
-qvm-run vmname command [aguments]
+qvm-run vmname command [arguments]
 
 OPTIONS
 -------

releases/supported-versions.md

@@ -45,7 +45,7 @@ supported.
 | Release 3.2      | TBA             | TBA                                           |
 | Release 4.0      | TBA             | TBA                                           |
 
-\* Denotes versions for which we have pubished the packages but have not done
+\* Denotes versions for which we have published the packages but have not done
 extensive testing.
 
 [r3.1-schedule]: /doc/releases/3.1/schedule/

security/multifactor-authentication.md

@@ -54,7 +54,7 @@ SMS:
    over to government agencies.)
 
  * Using `oathtool` in a dedicated, network-isolated Qubes VM allows us to
-   achieve a unqiue combination of security and convenience. The strong isolation
+   achieve a unique combination of security and convenience. The strong isolation
    Qubes provides allows us to reap the full security benefits of MFA, while
    virtualization frees us from having to worry about finding and handling a
    second physical device.

security/yubi-key.md

@@ -13,7 +13,7 @@ Using YubiKey to Qubes authentication
 You can use YubiKey to enhance Qubes user authentication, for example to mitigate
 risk of snooping the password. This can also slightly improve security when you have [USB keyboard](https://github.com/marmarek/qubes-app-linux-input-proxy).
 
-There (at least) two possible configurations: using OTP mode and using challenge-reponse mode.
+There (at least) two possible configurations: using OTP mode and using challenge-response mode.
 
 OTP mode
 --------