From 617330d02615cbad2d219639cd58506e83f82807 Mon Sep 17 00:00:00 2001 From: Tobias Killer Date: Fri, 16 Apr 2021 19:45:56 +0200 Subject: [PATCH 1/6] Resolve open issues mentioned on Transifex --- developer/building/development-workflow.md | 4 ++-- developer/general/gsod.md | 2 +- user/common-tasks/backup-restore.md | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/developer/building/development-workflow.md b/developer/building/development-workflow.md index 2b91c597..e9ca27bc 100644 --- a/developer/building/development-workflow.md +++ b/developer/building/development-workflow.md @@ -19,7 +19,7 @@ assumes you're using qubes-builder to build Qubes. # Repositories and committing Code -Qubes is split into a bunch of git repos. This are all contained in the +Qubes is split into a bunch of git repos. These are all contained in the `qubes-src` directory under qubes-builder. Subdirectories there are separate components, stored in separate git repositories. @@ -153,7 +153,7 @@ RPMS will appear in qubes-src/linux-kernel/pkgs/fc20/x86\_64: if all repository are tagged with signed tag. 2. `make show-vtags` - show version of each component (based on git tags) - mostly useful just before building ISO. **Note:** this will not show version -for components containing changes since last version tag +for components containing changes since last version tag. 3. `make push` - push change from **all** repositories to git server. You must set proper remotes (see above) for all repositories first. 4. `make prepare-merge` - fetch changes from remote repositories (can be diff --git a/developer/general/gsod.md b/developer/general/gsod.md index 942397e7..a297d5b4 100644 --- a/developer/general/gsod.md +++ b/developer/general/gsod.md @@ -94,7 +94,7 @@ Here are some successful projects which have been implemented in the past by Goo **Project**: Consolidate troubleshooting guides **Brief explanation**: Troubleshooting guides are scattered across many pages and sometimes incomplete, leading to repeatedly posting the same instruction over and over when helping users to diagnose problems. -This could be helped by writing consolidated guide with with a clear list of symptom-action layout. +This could be helped by writing a consolidated guide with a clear list of symptom-action layout. **Expected results**: diff --git a/user/common-tasks/backup-restore.md b/user/common-tasks/backup-restore.md index 211b1b6e..d80a4c89 100644 --- a/user/common-tasks/backup-restore.md +++ b/user/common-tasks/backup-restore.md @@ -114,7 +114,7 @@ This brings up the **Qubes Restore VMs** window. 4. If your backup is encrypted, you must check the **Encrypted backup** box. If a passphrase was supplied during the creation of your backup (regardless of whether it is encrypted), then you must supply it here. - **Note:** The passphrase which was supplied when the backup was created was used for **both** encryption/decryption and integrity verification. + **Note:** The passphrase which was supplied when the backup was created is used for **both** encryption/decryption and integrity verification. If the backup was not encrypted, the supplied passphrase is used only for integrity verification. All backups made from a Qubes R4.0 system will be encrypted. From 190b740e32006358a7aaed3f9c60ace2ea37e6c3 Mon Sep 17 00:00:00 2001 From: Tobias Killer Date: Sat, 17 Apr 2021 10:31:11 +0200 Subject: [PATCH 2/6] Resolve open issues mentioned on Transifex --- developer/building/development-workflow.md | 8 ++++---- developer/building/qubes-builder.md | 2 +- developer/general/gsoc.md | 2 +- developer/services/dom0-secure-updates.md | 2 +- 4 files changed, 7 insertions(+), 7 deletions(-) diff --git a/developer/building/development-workflow.md b/developer/building/development-workflow.md index e9ca27bc..0ec9fd95 100644 --- a/developer/building/development-workflow.md +++ b/developer/building/development-workflow.md @@ -117,7 +117,7 @@ cd ../.. vi series.conf ~~~ -#### Building RPMS +#### Building RPMs TODO: Is this step generic for all subsystems? @@ -130,13 +130,13 @@ distinguish between different versions of the same package. You might want to take a moment here to review (git diff, git status), commit your changes locally. -To actually build RPMS, in qubes-builder: +To actually build RPMs, in qubes-builder: ~~~ make linux-kernel ~~~ -RPMS will appear in qubes-src/linux-kernel/pkgs/fc20/x86\_64: +RPMs will appear in qubes-src/linux-kernel/pkgs/fc20/x86\_64: ~~~ -rw-rw-r-- 1 user user 42996126 Nov 17 04:08 kernel-3.4.18-1debug20121116c.pvops.qubes.x86_64.rpm @@ -166,7 +166,7 @@ FETCH_HEAD` (in each repo directory). Or `make do-merge` to merge all of them. When developing it is convenient to be able to rapidly test changes. Assuming you're developing Qubes on Qubes, you should be working in a special VM for -Qubes and occasionally you will want to transfer code or rpms back to dom0 for +Qubes and occasionally you will want to transfer code or RPMs back to dom0 for testing. Here are some handy scripts Marek has shared to facilitate this. diff --git a/developer/building/qubes-builder.md b/developer/building/qubes-builder.md index b4353ff8..939cbb26 100644 --- a/developer/building/qubes-builder.md +++ b/developer/building/qubes-builder.md @@ -99,7 +99,7 @@ cp example-configs/qubes-os-master.conf builder.conf make get-sources -# And now to build all Qubes rpms (this will take a few hours): +# And now to build all Qubes RPMs (this will take a few hours): make qubes diff --git a/developer/general/gsoc.md b/developer/general/gsoc.md index 73d3c1f0..44b44a7b 100644 --- a/developer/general/gsoc.md +++ b/developer/general/gsoc.md @@ -332,7 +332,7 @@ immune to altering past entries. See in files there, no file manager, etc). - Configure GNOME to not look into external devices plugged in (no auto mounting, device notifications etc). -- Package above modifications as rpms, preferably as extra configuration files +- Package above modifications as RPMs, preferably as extra configuration files and/or plugins than overwriting existing files. Exceptions to this rule may apply if no other option. - Adjust comps.xml (in installer-qubes-os repo) to define package group with diff --git a/developer/services/dom0-secure-updates.md b/developer/services/dom0-secure-updates.md index 1636c026..e8adf33e 100644 --- a/developer/services/dom0-secure-updates.md +++ b/developer/services/dom0-secure-updates.md @@ -44,7 +44,7 @@ The qubes-receive-updates script processes the untrusted input from Update VM: i Once qubes-receive-updates finished unpacking and verifying the updates, the updates are placed in ``qubes-receive-updates`` directory in Dom0 filesystem. Those updates are now trusted. Dom0 is configured (see /etc/yum.conf in Dom0) to use this directory as a default (and only) [yum repository](https://github.com/QubesOS/qubes-core-admin-linux/blob/release2/dom0-updates/qubes-cached.repo). -Finally, qubes-dom0-update runs ``yum update`` that fetches the rpms from qubes-cached repo and installs them as usual. +Finally, qubes-dom0-update runs ``yum update`` that fetches the RPMs from qubes-cached repo and installs them as usual. Security benefit of our update mechanism ---------------------------------------- From 6b33020140e3cc334b423b604832f66843f9ce6a Mon Sep 17 00:00:00 2001 From: Tobias Killer Date: Sat, 17 Apr 2021 10:45:27 +0200 Subject: [PATCH 3/6] Resolve open issues mentioned on Transifex --- introduction/faq.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/introduction/faq.md b/introduction/faq.md index 01c59c69..8994d63e 100644 --- a/introduction/faq.md +++ b/introduction/faq.md @@ -114,7 +114,7 @@ These programs are popular because they're designed primarily to be easy to use However, the fact that Type 2 hypervisors run under the host OS means that they're really only as secure as the host OS itself. If the host OS is ever compromised, then any VMs it hosts are also effectively compromised. -By contrast, Qubes uses a "Type 1" or "bare metal" hypervisor called [Xen](https://www.xenproject.org/). +By contrast, Qubes uses a "Type 1" or "bare-metal" hypervisor called [Xen](https://www.xenproject.org/). Instead of running inside an OS, Type 1 hypervisors run directly on the "bare metal" of the hardware. This means that an attacker must be capable of subverting the hypervisor itself in order to compromise the entire system, which is vastly more difficult. From 098f5b418c4236d1c1d937146e7aa0c462591c75 Mon Sep 17 00:00:00 2001 From: Tobias Killer Date: Sat, 17 Apr 2021 10:57:16 +0200 Subject: [PATCH 4/6] Resolve open issues mentioned on Transifex --- introduction/faq.md | 4 ++-- user/advanced-configuration/salt.md | 8 ++++---- .../upgrade/upgrade-to-r3_1.md | 2 +- user/hardware/system-requirements.md | 2 +- user/security-in-qubes/anti-evil-maid.md | 2 +- user/troubleshooting/usb-troubleshooting.md | 4 ++-- 6 files changed, 11 insertions(+), 11 deletions(-) diff --git a/introduction/faq.md b/introduction/faq.md index 8994d63e..1f8b9f55 100644 --- a/introduction/faq.md +++ b/introduction/faq.md @@ -459,10 +459,10 @@ In your TemplateVMs, open a terminal and run `sudo dnf upgrade`. Enable "debug mode" in the qube's settings, either by checking the box labeled "Run in debug mode" in the Qubes VM Manager qube settings menu or by running the `qvm-prefs` command. -### I created a usbVM and assigned usb controllers to it. Now the usbVM wont boot. +### I created a USB VM and assigned USB controllers to it. Now the USB VM won't boot. This is probably because one of the controllers does not support reset. -See the [USB Troubleshooting guide](/doc/usb-troubleshooting/#usbvm-does-not-boot-after-creating-and-assigning-usb-controllers-to-it). +See the [USB Troubleshooting guide](/doc/usb-troubleshooting/#usb-vm-does-not-boot-after-creating-and-assigning-usb-controllers-to-it). ### I assigned a PCI device to a qube, then unassigned it/shut down the qube. Why isn't the device available in dom0? diff --git a/user/advanced-configuration/salt.md b/user/advanced-configuration/salt.md index 7faaa4f4..c19b2039 100644 --- a/user/advanced-configuration/salt.md +++ b/user/advanced-configuration/salt.md @@ -431,16 +431,16 @@ System NetVM #### `qvm.sys-usb` -System UsbVM +System USB VM #### `qvm.sys-net-with-usb` -System UsbVM bundled into NetVM. Do not enable together with `qvm.sys-usb`. +System USB VM bundled into NetVM. Do not enable together with `qvm.sys-usb`. #### `qvm.usb-keyboard` -Enable USB keyboard together with USBVM, including for early system boot (for LUKS passhprase). -This state implicitly creates a USBVM (`qvm.sys-usb` state), if not already done. +Enable USB keyboard together with USB VM, including for early system boot (for LUKS passhprase). +This state implicitly creates a USB VM (`qvm.sys-usb` state), if not already done. #### `qvm.sys-firewall` diff --git a/user/downloading-installing-upgrading/upgrade/upgrade-to-r3_1.md b/user/downloading-installing-upgrading/upgrade/upgrade-to-r3_1.md index 6b7e396f..52ac219d 100644 --- a/user/downloading-installing-upgrading/upgrade/upgrade-to-r3_1.md +++ b/user/downloading-installing-upgrading/upgrade/upgrade-to-r3_1.md @@ -114,7 +114,7 @@ Maid passphrase to the new configuration. Please consult the Anti Evil Maid If you use USB VM, you may encounter problem with starting it on updated Xen version (because of strict default settings). Take a look at -[User FAQ](/faq/#i-created-a-usbvm-and-assigned-usb-controllers-to-it-now-the-usbvm-wont-boot) +[User FAQ](/faq/#i-created-a-usb-vm-and-assigned-usb-controllers-to-it-now-the-usb-vm-wont-boot) for details. Once you have upgraded dom0, you can install new templates from Qubes R3.1 diff --git a/user/hardware/system-requirements.md b/user/hardware/system-requirements.md index 36b4bfe5..e27db6f3 100644 --- a/user/hardware/system-requirements.md +++ b/user/hardware/system-requirements.md @@ -63,7 +63,7 @@ title: System Requirements In addition to the convenience of having a portable copy of Qubes, this allows users to test for hardware compatibility on multiple machines (e.g., at a brick-and-mortar computer store) before deciding on which computer to purchase. (See [hcl-report](/doc/hcl/#generating-and-submitting-new-reports) for advice on hardware compatibility testing.) - Remember to change the devices assigned to your NetVM and USBVM if you move between different machines. + Remember to change the devices assigned to your NetVM and USB VM if you move between different machines. - [Advice on finding a VT-d capable notebook](https://groups.google.com/d/msg/qubes-users/Sz0Nuhi4N0o/ZtpJdoc0OY8J). - You can check whether an Intel processor has VT-x and VT-d on [ark.intel.com](https://ark.intel.com/content/www/us/en/ark.html#@Processors). diff --git a/user/security-in-qubes/anti-evil-maid.md b/user/security-in-qubes/anti-evil-maid.md index 4c5015be..47473c66 100644 --- a/user/security-in-qubes/anti-evil-maid.md +++ b/user/security-in-qubes/anti-evil-maid.md @@ -53,7 +53,7 @@ Therefore, it is up to each individual Qubes user to evaluate the relative risk For example, a user who frequently travels with a Qubes laptop holding sensitive data may be at a much higher risk of Evil Maid attacks than a home user with a stationary Qubes desktop. If the frequent traveler judges her risk of an Evil Maid attack to be higher than the risk of a malicious USB device, she might reasonably opt to install and use AEM. On the other hand, the home user might deem the probability of an Evil Maid attack occurring in her own home to be so low that there is a higher probability that any USB drive she purchases is already compromised, in which case she might reasonably opt never to attach any USB devices directly to dom0. -(In either case, users can--and should--secure dom0 against further USB-related attacks through the use of a [USBVM](https://github.com/Qubes-Community/Contents/blob/master/docs/security/security-guidelines.md#creating-and-using-a-usbvm).) +(In either case, users can--and should--secure dom0 against further USB-related attacks through the use of a [USB VM](https://github.com/Qubes-Community/Contents/blob/master/docs/security/security-guidelines.md#creating-and-using-a-usbvm).) For more information, please see [this discussion thread](https://groups.google.com/d/msg/qubes-devel/EBc4to5IBdg/n1hfsHSfbqsJ). diff --git a/user/troubleshooting/usb-troubleshooting.md b/user/troubleshooting/usb-troubleshooting.md index f83ac75d..137dc6e3 100644 --- a/user/troubleshooting/usb-troubleshooting.md +++ b/user/troubleshooting/usb-troubleshooting.md @@ -34,7 +34,7 @@ After attaching a device to a qube, upon attempting to use the device results in As a first line of defense, increase the amount of memory given to the USB VM (sys-usb). High-bandwidth devices such as webcams have been [observed](https://github.com/QubesOS/qubes-issues/issues/6200) to need more memory in sys-usb. If increasing the amount of memory does not resolve the issue, check kernel logs within sys-usb as well as the attached qube for errors before filing a bug report. -## usbVM does not boot after creating and assigning USB controllers to it +## USB VM does not boot after creating and assigning USB controllers to it This is probably because one of the controllers does not support reset. In Qubes R2 any such errors were ignored. In Qubes R3.x they are not. @@ -43,7 +43,7 @@ In R4.x, devices that are automatically added to sys-net and sys-usb on install A device that does not support reset is not ideal and generally should not be assigned to a VM. Most likely the offending controller is a USB 3.0 device. -You can remove this controller from the usbVM, and see if this allows the VM to boot. +You can remove this controller from the USB VM, and see if this allows the VM to boot. Alternatively you may be able to disable USB 3.0 in the BIOS. If the BIOS does not have the option to disable USB 3.0, try running the following command in dom0 to force USB 2.0 modes for the USB ports: From bcbeae7463e204eaba2da261b228195d639beae1 Mon Sep 17 00:00:00 2001 From: Tobias Killer Date: Sat, 17 Apr 2021 11:03:50 +0200 Subject: [PATCH 5/6] Resolve open issues mentioned on Transifex --- introduction/faq.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/introduction/faq.md b/introduction/faq.md index 1f8b9f55..e675bce2 100644 --- a/introduction/faq.md +++ b/introduction/faq.md @@ -554,7 +554,7 @@ A fully encrypted drive does not appear in Nautilus. The workaround is to manually decrypt and mount the drive: -1. Attach usb device to qube - it should be attached as `/dev/xvdi` or similar. +1. Attach USB device to qube - it should be attached as `/dev/xvdi` or similar. 2. `sudo cryptsetup open /dev/xvdi bk --type luks` 3. `sudo cryptsetup status /dev/mapper/bk` (Shows useful status info.) 4. `sudo mount /dev/mapper/bk /mnt` @@ -563,7 +563,7 @@ The decrypted device is now available at `/mnt` - when you have finished using i 1. `sudo umount /mnt` 2. `sudo cryptsetup close bk --type luks` -3. Remove usb from qube. +3. Remove USB from qube. ### Windows Update is stuck. From a2c0565e2c17263db793004bb35af8036a22d747 Mon Sep 17 00:00:00 2001 From: Tobias Killer Date: Sun, 18 Apr 2021 08:32:11 +0200 Subject: [PATCH 6/6] Repair broken link --- user/advanced-configuration/usb-qubes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/user/advanced-configuration/usb-qubes.md b/user/advanced-configuration/usb-qubes.md index 6e0d5e25..0e2b469d 100644 --- a/user/advanced-configuration/usb-qubes.md +++ b/user/advanced-configuration/usb-qubes.md @@ -54,7 +54,7 @@ Alternatively, you can create a USB qube manually as follows: 5. Recommended: Check the box on the "Basic" tab which says "Start VM automatically on boot". (This will help to mitigate attacks in which someone forces your system to reboot, then plugs in a malicious USB device.) -If the USB qube will not start, please have a look at the [faq](/faq/#i-created-a-usbvm-and-assigned-usb-controllers-to-it-now-the-usbvm-wont-boot). +If the USB qube will not start, please have a look at the [faq](/faq/#i-created-a-usb-vm-and-assigned-usb-controllers-to-it-now-the-usb-vm-wont-boot). ## Enable a USB keyboard for login ##