Git-Mirrors/qubes-doc
1
0
Fork 0
mirror of https://github.com/QubesOS/qubes-doc.git synced 2025-05-02 06:46:11 -04:00
Code Issues Projects Releases Packages Wiki Activity

Move current pages to /en/ subdirectory

Browse source
This commit is contained in:
Axon 2015-10-11 07:29:00 +00:00
parent f3ee78f223
commit a91496e9d6
No known key found for this signature in database
GPG key ID: 8CE137352A019A17
159 changed files with 2 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

75
installing/InstallSecurity.md
View file

@ -1,75 +0,0 @@
---
layout: doc
title: InstallSecurity
permalink: /en/doc/install-security/
redirect_from:
- /doc/InstallSecurity/
- /wiki/InstallSecurity/
---
# Installation Security Considerations #
## Verifying the Qubes ISO ##
You should [verify][] the PGP signature on your Qubes ISO before you install
from it. However, if the machine on which you attempt the verification process
is already compromised, it could falsely claim that a malicious ISO has a good
signature. Therefore, in order to be certain that your Qubes ISO is trustworthy,
you require a trustworthy machine. But how can you be certain *that* machine is
trustworthy? Only by using another trusted machine, and so forth. This is a
[classic problem][trusting-trust]. While various [solutions][countering] have
been proposed, the point is that each user must ultimately make a choice about
whether to trust that a file is non-malicious.
## Choosing an Installation Medium ##
So, after taking some measures to verify its integrity and authenticity, you've
decided to trust your Qubes ISO. Great! Now you must decide what sort of medium
on which to write it so that you can install from it. From a Qubes-specific
security perspective, each has certain pros and cons.
### USB Drives ###
Pros:
* Works via USB, including with a [USBVM][].
* Non-fixed capacity. (Easy to find one on which the ISO can fit.)
Cons:
* Rewriteable. (If the drive is mounted to a compromised machine, the ISO could
be maliciously altered after it has been written to the drive.)
* Untrustworthy firmware. (Firmware can be malicious even if the drive is new.
Plugging a drive with rewriteable firmware into a compromised machine can
also [compromise the drive][BadUSB]. Installing from a compromised drive
could compromise even a brand new Qubes installation.)
### Optical Discs ###
Pros:
* Read-only available. (If you use read-only media, you don't have to worry
about the ISO being maliciously altered after it has been written to the
disc. You then have the option of verifying the signature on multiple
different machines.)
Cons:
* Fixed capacity. (If the size of the ISO is larger than your disc, it will be
inconvenient.)
* Passthrough burning is not supported by Xen. (This mainly applies if you're
upgrading from a previous version of Qubes.) Currently, the only options for
burning optical discs in Qubes are:
1. Use a USB optical drive.
2. Attach a SATA optical drive to a secondary SATA controller, then assign
this secondary SATA controller to an AppVM.
3. Use a SATA optical drive attached to dom0.
(Option 3 violates the Qubes security model since it entails transferring
an untrusted ISO to dom0 in order to burn it to disc, which leaves only
the other two options.)
[verify]: https://www.qubes-os.org/doc/VerifyingSignatures/
[trusting-trust]: http://www.acm.org/classics/sep95/
[countering]: http://www.dwheeler.com/trusting-trust/
[USBVM]: https://www.qubes-os.org/doc/SecurityGuidelines/#creating-and-using-a-usbvm
[BadUSB]: https://srlabs.de/badusb/

99
installing/InstallationGuide.md
View file

@ -1,99 +0,0 @@
---
layout: doc
title: Installation Guide
permalink: /en/doc/installation-guide/
redirect_from:
- /doc/InstallationGuide/
- /wiki/InstallationGuide/
redirect_from:
-
- /doc/InstallationGuideR1/
redirect_from:
-
- /doc/InstallationGuideR2B1/
redirect_from:
-
- /doc/InstallationGuideR2B2/
redirect_from:
-
- /doc/InstallationGuideR2B3/
redirect_from:
-
- /doc/InstallationGuideR2rc1/
redirect_from:
-
- /doc/InstallationGuideR2rc2/
redirect_from:
-
- /doc/InstallationGuideR3.0rc1/
redirect_from:
-
- /doc/InstallationGuideR3.0rc2/
---
Installation Guide
========================================
1. [Hardware Requirements](#hardware-requirements)
2. [Download installer ISO](#download-installer-iso)
3. [Burning the ISO onto a DVD or USB stick](#burning-the-iso-onto-a-dvd-or-usb-stick)
4. [Upgrading](#upgrading)
5. [Troubleshooting problems with the installer](#troubleshooting-problems-with-the-installer)
6. [Getting Help](#getting-help)
Hardware Requirements
---------------------
Please see the [Hardware Compatibility List](/hcl/) page for more information on required and recommended hardware.
Note: We don't recommend installing Qubes in a virtual machine! It will likely not work. Don't send emails asking about it. However, you can install it on an external USB hard drive and run from it, at least for testing (normally such disks are *orders* of magnitude slower than even the slowest internal hard drives).
Download installer ISO
----------------------
See [this page](/doc/QubesDownloads/) for ISO downloads. Remember, we have absolutely no control over those servers, and so you should be assuming that they might be compromised, or just be serving a compromised ISOs because their operators decided so, for whatever reason. Always verify the digital signature on the downloaded ISO. See this [page](/en/doc/verifying-signatures/) for more info about how to download and verify our GPG keys, and then verify the downloaded ISO:
gpg -v Qubes-R2-x86_64-DVD.iso.asc
Adjust filename to the version you're installing.
Burning the ISO onto a DVD or USB stick
---------------------------------------
Once you verify this is an authentic ISO, you should burn it on a DVD.
If you prefer to use USB as a source for installation, then you just need to copy the ISO onto the USB device, e.g. using dd:
dd if=Qubes-R2-x86_64-DVD.iso of=/dev/sdX
Adjust filename to the version you're installing. **Be sure to use a correct device as the target in the dd command above (instead of sdX)'''**
On windows you can use [Rufus](http://rufus.akeo.ie/) tool. Be sure to select "DD image" mode (you need to do that **after** selecting Qubes iso image):
<img src="/attachment/wiki/InstallationGuide/rufus-main-boxed.png" height="350">
Before proceeding with the installation, you are encouraged to first read all the information on this page, especially the *Known Issues* paragraph.
Then, when finally ready, boot your system from the installer DVD and follow the instructions on screen. The installer is very simple and asks very few questions -- it's actually easier to install Qubes right now than most other Linux distributions!
The installer loads Xen right at the beginning, so chances are high that if you can see the installer's graphical screen, Qubes will work on your system :)
Upgrading
---------
See [release notes](/doc/releases/) of appropriate version.
Getting Help
------------
- **User manuals are [here](/en/doc/).** (Strongly recommended!)
- Developers documentation (normally not needed by users) is [here](/en/doc/system-doc/)
- If you don't find answer in the sources given above, write to the *qubes-users* mailing list (you don't need to be subscribed to the list, just send email to the address given below):
- [https://groups.google.com/group/qubes-users](https://groups.google.com/group/qubes-users)
- `qubes-users@googlegroups.com`
- Please do not write email to individual developers (Marek, Joanna, etc) asking questions about installation or other problems. Please send all such questions to the mailing list.

65
installing/UpgradeToR2.md
View file

@ -1,65 +0,0 @@
---
layout: doc
title: UpgradeToR2
permalink: /en/doc/upgrade-to-r2/
redirect_from:
- /doc/UpgradeToR2/
- /doc/UpgradeToR2rc1/
redirect_from:
-
- /wiki/UpgradeToR2rc1/
---
Upgrading Qubes R2 Beta 3 to R2
===================================
Current Qubes R2 Beta 3 (R2B3) systems can be upgraded in-place to the latest R2 (R2) release by following the procedure below.
**Before attempting either an in-place upgrade or a clean installation, we strongly recommend that users back up the system by using the built-in [backup tool](/en/doc/backup-restore/).**
Upgrade Template and Standalone VM(s)
-------------------------------------
- Qubes R2 comes with new template based on Fedora 20. You can upgrade existing template according to procedure described [here](/doc/FedoraTemplateUpgrade/).
- **It also possible to download a new Fedora 20-based template from our repositories**. To do this please first upgrade the Dom0 distro as described in the section below.
While technically it is possible to use old Fedora 18 template on R2, it is strongly recommended to upgrade all the Template VMs and Standalone VMs, because Fedora 18 no longer receive security updates.
By default, in Qubes R2, there is only one Template VM, however users are free to create more Template VMs for special purposes, as well as Standalone VMs. If more than one template and/or Standalone VMs are used, then it is recommended to upgrade/replace all of them. More information on using multiple Template VMs, as well as Standalone VMs, can be found [here](/en/doc/software-update-vm/).
Upgrading dom0
--------------
Note that dom0 in R2 is based on Fedora 20, in contrast to Fedora 18 in previous release, so this operation will upgrade a lot of packages.
1. Open terminal in Dom0. E.g. Start-\>System Settings-\>Konsole.
1. Install all the updates for Dom0:
~~~
sudo qubes-dom0-update
~~~
After this step you should have `qubes-release-2-5` in your Dom0. Important: if you happen to have `qubes-release-2-6*` then you should downgrade to `qubes-release-2-5`! The `qubes-release-2-6*` packages have been uploaded to the testing repos and were kept there for a few hours, until we realized they bring incorrect repo definitions and so we removed them and also have changed the update procedure a bit (simplifying it).
1. Upgrade dom0 to R2:
Note: be sure that the VM used as a update-downloading-vm (by default its the firewallvm based on the default template) has been updated to the latest qubes packages, specifically `qubes-core-vm-2.1.33` or later. This doesn't imply that the VM must already be upgraded to fc20 -- for Dom0 upgrade we could still use an fc18-based VM (updatevm) it is only important to install the latest Qubes packages there.
~~~
sudo qubes-dom0-update qubes-dom0-dist-upgrade
sudo qubes-dom0-update
~~~
1. If above step completed successfully you should have `qubes-release-2-9` or later. If not, repeat above step with additional `--clean` option.
4a. If you chose not to upgrade your fc18 templates, but instead to download our new fc20-based template you should now be able to do that by simply typing:
~~~
sudo qubes-dom0-update qubes-template-fedora-20-x64
~~~
1. Reboot the system.
Please note that if you use Anti Evil Maid, then it won't be able to unseal the passphrase this time, because the Xen, kernel, and initramfs binaries have changed. Once the system boots up again, you could reseal your Anti Evil Maid's passphrase to the new configuration. Please consult Anti Evil Maid documentation for explanation on how to do that.

76
installing/UpgradeToR2b1.md
View file

@ -1,76 +0,0 @@
---
layout: doc
title: UpgradeToR2B1
permalink: /en/doc/upgrade-to-r2b1/
redirect_from:
- /doc/UpgradeToR2B1/
- /wiki/UpgradeToR2B1/
---
Upgrading Qubes R1 to R2 Beta 1
===============================
**Note: Qubes R2 Beta 1 is no longer supported! Please install or upgrade to a newer Qubes R2.**
**Note: This page is kept for historical reasons only! Do not follow the instructions below'''**
Existing users of Qubes R1 (but not R1 betas!) can upgrade their systems to the latest R2 beta release by following the procedure below. As usual, it is advisable to backup the system before proceeding with the upgrade
Upgrade all Template and Standalone VM(s)
-----------------------------------------
By default, in Qubes R1, there is only one Template VM, however users are free to create more Template VMs for special purposes, as well as Standalone VMs. More information on using multiple Template VMs, as well as Standalone VMs, can be found [SoftwareUpdateVM here]. The steps described in this section should be repeated in *all* user's Template and Standalone VMs.
1. Open terminal in the template VM (or standalone VM). E.g. use the Qubes Manager's right-click menu and choose Run Command in VM and type `gnome-terminal` there.
2. Install `qubes-upgrade-vm` package (this package brings in R2 repo definitions and R2 keys)
~~~
sudo yum install qubes-upgrade-vm
~~~
3. Proceed with normal update in the template (this should bring in also the R2 packages for the VMs):
~~~
sudo yum update
~~~
The installer (yum) will prompt to accept the new Qubes R2 signing key:
~~~
Importing GPG key 0x0A40E458:
Userid : "Qubes OS Release 2 Signing Key"
Fingerprint: 3f01 def4 9719 158e f862 66f8 0c73 b9d4 0a40 e458
Package : qubes-upgrade-vm-1.0-1.fc17.x86_64 (@qubes-vm-current)
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-upgrade-qubes-2-primary
Is this ok [y/N]:
~~~
If you see (as is the case on the "screenshot" above) that the new key was imported from a local filesystem (`/etc/pki/rpm-gpg/...`) you can safely accept the key, without checking its fingerprint. This is because there were only two ways for such a key to make it to your Template VM's filesystem:
- via a legitimate RPM package previously installed (in our case it was the `qubes-upgrade-vm` RPM). Such an RPM must have been signed by one of the keys you decided to trust previously, by default this would be either via the Qubes R1 signing key, or Fedora 17 signing key.
- via system compromise or via some illegal RPM package (e.g. Fedora released package pretending to bring new Firefox). In that case, however, your VM is already compromised, and it careful checking of the new R2 key would not change this situation to any better one. The game is lost for this VM anyway (and all VMs based on this template).
1. Shut down the VM.
Upgrade Dom0
------------
Be sure to do steps described in this section after *all* your template and standalone VMs got updated as described in the section above.
1. Open terminal in Dom0. E.g. Start-\>System Settings-\>Konsole.
2. Upgrade the `qubes-release` package to the latest version which brings in new repo definitions and R2 signing keys:
~~~
sudo qubes-dom0-update qubes-release
~~~
This should install `qubes-release-1-6` in your Dom0.
3. Install R2 packages:
~~~
sudo qubes-dom0-update --releasever=2
~~~
4. Reboot your system. Please note that if you use Anti Evil Maid, then it won't be able to unseal the passphrase this time, because the Xen, kernel, and initramfs binaries have changed. Once the system boots up again, you could reseal your Anti Evil Maid's passphrase to the new configuration. Please consult Anti Evil Maid documentation for explanation on how to do that.

108
installing/UpgradeToR2b2.md
View file

@ -1,108 +0,0 @@
---
layout: doc
title: UpgradeToR2B2
permalink: /en/doc/upgrade-to-r2b2/
redirect_from:
- /doc/UpgradeToR2B2/
- /wiki/UpgradeToR2B2/
---
Upgrading Qubes R1 to R2 (beta2)
================================
Existing users of Qubes R1 (but not R1 betas!) can upgrade their systems to the latest R2 beta release by following the procedure below. As usual, it is advisable to backup the system before proceeding with the upgrade. While it is possible to upgrade the system **it is strongly recommended to reinstall it**. You will preserve all your data and settings thanks to [backup and restore tools](/en/doc/backup-restore/).
Upgrade all Template and Standalone VM(s)
-----------------------------------------
**If you have already R2 Beta1 installed, follow standard template update procedure (e.g. "Update VM" buttom in Qubes Manager) and skip the rest of this section**
By default, in Qubes R1, there is only one Template VM, however users are free to create more Template VMs for special purposes, as well as Standalone VMs. More information on using multiple Template VMs, as well as Standalone VMs, can be found [SoftwareUpdateVM here]. The steps described in this section should be repeated in *all* user's Template and Standalone VMs.
1. Open terminal in the template VM (or standalone VM). E.g. use the Qubes Manager's right-click menu and choose Run Command in VM and type `gnome-terminal` there.
2. Install `qubes-upgrade-vm` package (this package brings in R2 repo definitions and R2 keys)
~~~
sudo yum install qubes-upgrade-vm
~~~
3. Proceed with normal update in the template (this should bring in also the R2 packages for the VMs):
~~~
sudo yum update
~~~
The installer (yum) will prompt to accept the new Qubes R2 signing key:
~~~
Importing GPG key 0x0A40E458:
Userid : "Qubes OS Release 2 Signing Key"
Fingerprint: 3f01 def4 9719 158e f862 66f8 0c73 b9d4 0a40 e458
Package : qubes-upgrade-vm-1.0-1.fc17.x86_64 (@qubes-vm-current)
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-upgrade-qubes-2-primary
Is this ok [y/N]:
~~~
If you see (as is the case on the "screenshot" above) that the new key was imported from a local filesystem (`/etc/pki/rpm-gpg/...`) you can safely accept the key, without checking its fingerprint. This is because there were only two ways for such a key to make it to your Template VM's filesystem:
- via a legitimate RPM package previously installed (in our case it was the `qubes-upgrade-vm` RPM). Such an RPM must have been signed by one of the keys you decided to trust previously, by default this would be either via the Qubes R1 signing key, or Fedora 17 signing key.
- via system compromise or via some illegal RPM package (e.g. Fedora released package pretending to bring new Firefox). In that case, however, your VM is already compromised, and it careful checking of the new R2 key would not change this situation to any better one. The game is lost for this VM anyway (and all VMs based on this template).
1. Shut down the VM.
Installing new template
-----------------------
Qubes R2 Beta2 brings new fedora-18-x64 template (based on Fedora 18). You can install it from Qubes installation DVD. Insert installation DVD into your drive and issue following commmands:
~~~
$ sudo -s
# mkdir -p /mnt/cdrom
# mount /dev/cdrom /mnt/cdrom # you can also use ISO image instead of /dev/cdrom; then add -o loop option
# yum install /mnt/cdrom/Packages/q/qubes-template-fedora-18-x64*rpm
# umount /mnt/cdrom
~~~
If you already have fedora-17-x64, you can also upgrade it to fedora-18-x64 following [standard Fedora upgrade procedure](http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum) (only "yum" method will work in Qubes VM).
Upgrade Dom0
------------
Be sure to do steps described in this section after *all* your template and standalone VMs got updated as described in the section above.
1. Open terminal in Dom0. E.g. Start-\>System Settings-\>Konsole.
2. Upgrade the `qubes-release` package to the latest version which brings in new repo definitions and R2 signing keys:
~~~
sudo qubes-dom0-update qubes-release
~~~
This should install `qubes-release-1-6` in your Dom0.
3. Install R2 upgrade package:
~~~
sudo qubes-dom0-update --releasever=1 qubes-dist-upgrade
~~~
4. Start upgrade process:
~~~
sudo qubes-dist-upgrade
~~~
5. Follow instructions on screen, first stage of upgrade should end up with reboot request.
6. Reboot your system, ensure that you choose "Qubes Upgrade" boot option.
7. When system starts up, login and start start
~~~
sudo qubes-dist-upgrade
~~~
again. This will start second stage of upgrade, here most packages will be upgraded, so this will take a while.
8. You will be prompted to install new bootloader. If you haven't changed anything in this matter from initial installation, just accept the default.
9. Reboot your system. System shutdown may hung because some running system components no longer match that installed on disk; just wait a few minutes and hard reset the system in such case.
10. This is end of upgrade process, you should now have Qubes R2 system.
Please note that if you use Anti Evil Maid, then it won't be able to unseal the passphrase this time, because the Xen, kernel, and initramfs binaries have changed. Once the system boots up again, you could reseal your Anti Evil Maid's passphrase to the new configuration. Please consult Anti Evil Maid documentation for explanation on how to do that.

76
installing/UpgradeToR2b3.md
View file

@ -1,76 +0,0 @@
---
layout: doc
title: UpgradeToR2B3
permalink: /en/doc/upgrade-to-r2b3/
redirect_from:
- /doc/UpgradeToR2B3/
- /wiki/UpgradeToR2B3/
---
Upgrading Qubes R2 Beta 2 to R2 Beta 3
======================================
Current Qubes R2 Beta 2 (R2B2) systems can be upgraded in-place to the latest R2 Beta 3 (R2B3) release by following the procedure below. However, upgrading in-place is riskier than performing a clean installation, since there are more things which can go wrong. For this reason, **we strongly recommended that users perform a [clean installation](/en/doc/installation-guide/) of Qubes R2 Beta 3**.
**Before attempting either an in-place upgrade or a clean installation, we strongly recommend that users back up the system by using the built-in [backup tool](/en/doc/backup-restore/).**
Experienced users may be comfortable accepting the risks of upgrading in-place. Such users may wish to first attempt an in-place upgrade. If nothing goes wrong, then some time and effort will have been saved. If something does go wrong, then the user can simply perform a clean installation, and no significant loss will have occurred (as long as the user [backed up](/en/doc/backup-restore/) correctly!).
Upgrade all Template and Standalone VM(s)
-----------------------------------------
By default, in Qubes R2, there is only one Template VM, however users are free to create more Template VMs for special purposes, as well as Standalone VMs. More information on using multiple Template VMs, as well as Standalone VMs, can be found [here](/en/doc/software-update-vm/). The steps described in this section should be repeated in *all* user's Template and Standalone VMs.
It is critical to complete this step **before** proceeding to dom0 upgrade. Otherwise you will most likely ends with unusable system.
1. Open terminal in the template VM (or standalone VM). E.g. use the Qubes Manager's right-click menu and choose Run Command in VM and type `gnome-terminal` there.
2. Proceed with normal update in the template:
~~~
sudo yum update
~~~
3. Ensure that you've got qubes-core-vm package version 2.1.13-3.fc18:
~~~
rpm -q qubes-core-vm
~~~
4. Update the system to R2 beta3 packages:
~~~
sudo yum --enablerepo=qubes-vm-r2b3-current update
~~~
5. **Do not** shutdown the VM.
Upgrading dom0
--------------
Be sure to do steps described in this section after *all* your template and standalone VMs got updated as described in the section above. Also make sure you haven't shutdown any of: netvm, firewallvm, fedora-18-x64 (or to be more precise: template which your netvm and firewallvm is based on).
1. Open terminal in Dom0. E.g. Start-\>System Settings-\>Konsole.
2. Upgrade the `qubes-release` package to the latest version which brings in new repo definitions and R2 signing keys:
~~~
sudo qubes-dom0-update qubes-release
~~~
This should install `qubes-release-2-3.1` in your Dom0.
3. Upgrade dom0 to R2 beta3:
~~~
sudo qubes-dom0-update --enablerepo=qubes-dom0-r2b3-current
~~~
4. If above step completed successfully you should have qubes-core-dom0 at least 2.1.34. If not, repeat above step with additional `--clean` option.
5. Now is the time to shutdown all the VMs:
~~~
qvm-shutdown --all --wait
~~~
6. Reboot the system.
Please note that if you use Anti Evil Maid, then it won't be able to unseal the passphrase this time, because the Xen, kernel, and initramfs binaries have changed. Once the system boots up again, you could reseal your Anti Evil Maid's passphrase to the new configuration. Please consult Anti Evil Maid documentation for explanation on how to do that.

145
installing/UpgradeToR3.0.md
View file

@ -1,145 +0,0 @@
---
layout: doc
title: Upgrade to R3.0
permalink: /en/doc/upgrade-to-r3.0/
redirect_from:
- /doc/UpgradeToR3.0/
- /doc/UpgradeToR3.0rc1/
---
Upgrading Qubes R2 to R3.0
======================================
**This instruction is highly experimental, the official way to upgrade from R2 is to backup the data and reinstall the system. Use at your own risk!**
Current Qubes R3.0 (R3.0) systems can be upgraded in-place to the latest R3.0 by following the procedure below. However, upgrading in-place is riskier than performing a clean installation, since there are more things which can go wrong. For this reason, **we strongly recommended that users perform a [clean installation](/en/doc/installation-guide/) of Qubes R3.0**.
**Before attempting either an in-place upgrade or a clean installation, we strongly recommend that users back up the system by using the built-in [backup tool](/en/doc/backup-restore/).**
Experienced users may be comfortable accepting the risks of upgrading in-place. Such users may wish to first attempt an in-place upgrade. If nothing goes wrong, then some time and effort will have been saved. If something does go wrong, then the user can simply perform a clean installation, and no significant loss will have occurred (as long as the user [backed up](/en/doc/backup-restore/) correctly!).
Upgrade all Template and Standalone VM(s)
-----------------------------------------
By default, in Qubes R2, there is only one Template VM, however users are free to create more Template VMs for special purposes, as well as Standalone VMs. More information on using multiple Template VMs, as well as Standalone VMs, can be found [here](/en/doc/software-update-vm/). The steps described in this section should be repeated in **all** user's Template and Standalone VMs.
It is critical to complete this step **before** proceeding to dom0 upgrade. Otherwise you will most likely end with unusable system.
### Upgrade Fedora template:
1. Open terminal in the template VM (or standalone VM). E.g. use the Qubes Manager's right-click menu and choose Run Command in VM and type `gnome-terminal` there.
2. Install `qubes-upgrade-vm` package:
sudo yum install qubes-upgrade-vm
3. Proceed with normal update in the template:
sudo yum update
You'll need to accept "Qubes Release 3 Signing Key" - it is delivered by signed qubes-upgrade-vm package (verify that the message is about local file), so you don't need to manually verify it.
4. Shutdown the template VM.
### Upgrade Debian template:
1. Open terminal in the template VM (or standalone VM). E.g. use the Qubes Manager's right-click menu and choose Run Command in VM and type `gnome-terminal` there.
2. Update repository definition:
sudo cp /etc/apt/sources.list.d/qubes-r2.list
/etc/apt/sources.list.d/qubes-r3-upgrade.list
sudo sed -i 's/r2/r3.0/' /etc/apt/sources.list.d/qubes-r3-upgrade.list
3. Proceed with normal update in the template:
sudo apt-get update
sudo apt-get dist-upgrade
There will be some error messages during the process, but our tests does
not revealed any negative consequences.
Update of `qubesdb-vm` package will restart the service, which will fail
(after 3min timeout), but you can ignore this problem for now. After
completing the whole upgrade the service will be properly restarted.
4. Shutdown the template VM.
Upgrading dom0
--------------
Be sure to do steps described in this section after *all* your template and standalone VMs got updated as described in the section above. Also make sure you haven't shutdown any of: netvm, firewallvm - you will not be able to start them again.
1. Open terminal in Dom0. E.g. Start-\>System Settings-\>Konsole.
2. Upgrade the `qubes-release` package to the latest version which brings in new repo definitions and R2 signing keys:
sudo qubes-dom0-update qubes-release
This should install `qubes-release-2-12` in your Dom0.
3. Upgrade dom0 to R3.0:
sudo qubes-dom0-update --releasever=3.0
After this step, until you reboot the system, most of the qvm-* tools will not work.
4. If above step completed successfully you should have `qubes-core-dom0` at least 3.0.8. If not, repeat above step with additional `--clean` option.
5. Enable Xen services:
sudo systemctl enable xenconsoled.service xenstored.service
6. Reboot the system.
It may happen that the system hang during the reboot. Hard reset the system in such case, all the filesystems are unmounted at this stage.
Please note that if you use Anti Evil Maid, then it won't be able to unseal the passphrase this time, because the Xen, kernel, and initramfs binaries have changed. Once the system boots up again, you could reseal your Anti Evil Maid's passphrase to the new configuration. Please consult Anti Evil Maid documentation for explanation on how to do that.
Now, when you have dom0 upgraded, you can install new templates from Qubes R3.0 repositories. Especially Fedora 21 - default Qubes R3.0 template:
sudo qubes-dom0-update qubes-template-fedora-21
Upgrading template on already upgraded dom0
-------------------------------------------
When for some reason you did not upgraded all the templates and standalone VMs before upgrading dom0, you can still do this, but it will be somehow more complicated. This can be a case when you restore backup done on Qubes R2.
When you start R2 template/standalone VM on R3.0, there will be some limitations:
1. qrexec will not connect (you will see an error message during VM startup)
2. GUI will not connect - you will not see any VM window
3. VM will not be configured - especially it will not have network access
Because of above limitations, you will need to configure some of those manually. The instruction assumes the VM name is `custom-template`, but the same instructions can be applied to a standalone VM.
1.Check the VM network parameters, you will need them later:
[user@dom0 ~]$ qvm-ls -n custom-template
-------------------+----+--------+-------+------+-------------+-------+-------------+---------+-------------+
name | on | state | updbl | type | netvm | label | ip | ip back | gateway/DNS |
-------------------+----+--------+-------+------+-------------+-------+-------------+---------+-------------+
[custom-template] | | Halted | Yes | Tpl | *firewallvm | black | 10.137.1.53 | n/a | 10.137.1.1 |
2.Start the VM from command line:
[user@dom0 ~]$ qvm-start custom-template
--> Loading the VM (type = TemplateVM)...
--> Starting Qubes DB...
--> Setting Qubes DB info for the VM...
--> Updating firewall rules...
--> Starting the VM...
--> Starting the qrexec daemon...
Waiting for VM's qrexec agent.............................................................Cannot connect to 'custom-template' qrexec agent for 60 seconds, giving up
ERROR: Cannot execute qrexec-daemon!
You can interrupt with Ctrl-C that qrexec waiting process.
3.Access VM console:
[user@dom0 ~]$ virsh -c xen:/// console custom-template
4.Configure network according to parameters retrieved in first step:
ip addr add 10.137.1.53/32 dev eth0
ip route add 10.137.1.1/32 dev eth0
ip route add via 10.137.1.1
echo nameserver 10.137.1.1 > /etc/resolv.conf
5.Proceed with normal upgrade instruction described on this page.

200
installing/VerifyingSignatures.md
View file

@ -1,200 +0,0 @@
---
layout: doc
title: VerifyingSignatures
permalink: /en/doc/verifying-signatures/
redirect_from:
- /doc/VerifyingSignatures/
- /wiki/VerifyingSignatures/
---
On Digital Signatures and Key Verification
==========================================
What Digital Signatures Can and Cannot Prove
--------------------------------------------
Most people – even programmers – are confused about the basic concepts underlying digital signatures. Therefore, most people should read this section, even if it looks trivial at first sight.
Digital signatures can prove both **authenticity** and **integrity** to a reasonable degree of certainty. **Authenticity** ensures that a given file was indeed created by the person who signed it (i.e., that it was not forged by a third party). **Integrity** ensures that the contents of the file have not been tampered with (i.e., that a third party has not undetectably altered its contents *en route*).
Digital signatures **cannot** prove any other property, e.g., that the signed file is not malicious. In fact, there is nothing that could stop someone from signing a malicious program (and it happens from time to time in reality).
The point is, of course, that people must choose who they will trust (e.g., Linus Torvalds, Microsoft, the Qubes Project, etc.) and assume that if a given file was signed by a trusted party, then it should not be malicious or buggy in some horrible way. But the decision of whether to trust any given party is beyond the scope of digital signatures. It's more of a sociological and political decision.
Once we make the decision to trust certain parties, digital signatures are useful, because they make it possible for us to limit our trust only to those few parties we choose and not to worry about all the "Bad Things That Can Happen In The Middle" between us and them, e.g., server compromises (qubes-os.org will surely be compromised one day), dishonest IT staff at the hosting company, dishonest staff at the ISPs, Wi-Fi attacks, etc.
By verifying all the files we download which purport to be authored by a party we've chosen to trust, we eliminate concerns about the bad things discussed above, since we can easily detect whether any files have been tampered with (and subsequently choose to refrain from executing, installing, or opening them).
However, for digital signatures to make any sense, we must ensure that the public keys we use for signature verification are indeed the original ones. Anybody can generate a GPG key pair that purports to belong to "The Qubes Project," but of course only the key pair that we (i.e., the Qubes developers) generated is the legitimate one. The next section explains how to verify the validity of the Qubes signing keys.
Importing Qubes Signing Keys
----------------------------
Every file published by the Qubes Project (ISO, RPM, TGZ files and git repositories) is digitally signed by one of the developer or release signing keys. Each such key is signed by the Qubes Master Signing Key ([`0x36879494`](https://keys.qubes-os.org/keys/qubes-master-signing-key.asc)).
The public portion of the Qubes Master Signing Key can be imported directly from a [ keyserver](https://en.wikipedia.org/wiki/Key_server_%28cryptographic%29#Keyserver_examples) (specified on first use with --keyserver URI, keyserver saved in `~/.gnupg/gpg.conf`), e.g.,
gpg --keyserver pool.sks-keyservers.net --recv-keys 0x427F11FD0FAA4B080123F01CDDFA1A3E36879494
or downloaded [here](https://keys.qubes-os.org/keys/qubes-master-signing-key.asc) and imported with gpg,
$ gpg --import ./qubes-master-signing-key.asc
or fetched directly with gpg.
$ gpg --fetch-keys https://keys.qubes-os.org/keys/qubes-master-signing-key.asc
For additional security we also publish the fingerprint of the Qubes Master Signing Key ([`0x36879494`](https://keys.qubes-os.org/keys/qubes-master-signing-key.asc)) here in this document:
pub 4096R/36879494 2010-04-01
Key fingerprint = 427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494
uid Qubes Master Signing Key
There should also be a copy of this key at the project's main website, in the [Qubes Security Pack](/en/doc/security-pack/), and in the archives of the project's [developer](https://groups.google.com/forum/#!msg/qubes-devel/RqR9WPxICwg/kaQwknZPDHkJ) and [user](https://groups.google.com/d/msg/qubes-users/CLnB5uFu_YQ/ZjObBpz0S9UJ) mailing lists.
Once you have obtained the Qubes Master Signing Key ([`0x36879494`](https://keys.qubes-os.org/keys/qubes-master-signing-key.asc)), you should verify the fingerprint of this key very carefully by obtaining copies of the fingerprint from trustworthy independent sources and comparing them to the downloaded key's fingerprint to ensure they match. Then set its trust level to "ultimate" (oh, well), so that it can be used to automatically verify all the keys signed by the Qubes Master Signing Key:
$ gpg --edit-key 0x36879494
gpg (GnuPG) 1.4.18; Copyright (C) 2014 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
pub 4096R/36879494 created: 2010-04-01 expires: never usage: SC
trust: unknown validity: unknown
[ unknown] (1). Qubes Master Signing Key
gpg> fpr
pub 4096R/36879494 2010-04-01 Qubes Master Signing Key
Primary key fingerprint: 427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494
gpg> trust
pub 4096R/36879494 created: 2010-04-01 expires: never usage: SC
trust: unknown validity: unknown
[ unknown] (1). Qubes Master Signing Key
Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)
1 = I don't know or won't say
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
5 = I trust ultimately
m = back to the main menu
Your decision? 5
Do you really want to set this key to ultimate trust? (y/N) y
pub 4096R/36879494 created: 2010-04-01 expires: never usage: SC
trust: ultimate validity: unknown
[ unknown] (1). Qubes Master Signing Key
Please note that the shown key validity is not necessarily correct
unless you restart the program.
gpg> q
Now you can easily download any of the developer or release signing keys that happen to be used to sign particular ISO, RPM, TGZ files or git tags.
For example: Qubes OS Release 2 Signing Key ([`0x0A40E458`](https://keys.qubes-os.org/keys/qubes-release-2-signing-key.asc)) is used for all Release 2 ISO images.
$ gpg --recv-keys 0x3F01DEF49719158EF86266F80C73B9D40A40E458
gpg: requesting key 0A40E458 from hkp server keys.gnupg.net
gpg: key 0A40E458: public key "Qubes OS Release 2 Signing Key" imported
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 1 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1 valid: 1 signed: 0 trust: 1-, 0q, 0n, 0m, 0f, 0u
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
You can also download all the currently used developers' signing keys and current and older release signing keys (and also a copy of the Qubes Master Signing Key) from the [keys directory on our server](https://keys.qubes-os.org/keys/) and from the [Qubes Security Pack](/en/doc/security-pack/).
The developer signing keys are set to be valid for 1 year only, while the Qubes Master Signing Key ([`0x36879494`](https://keys.qubes-os.org/keys/qubes-master-signing-key.asc)) has no expiration date. This latter key was generated and is kept only within a dedicated, air-gapped "vault" machine, and the private portion will (hopefully) never leave this isolated machine.
You can now verify the ISO image (`Qubes-R2-x86_64-DVD.iso`) matches its signature (`Qubes-R2-x86_64-DVD.iso.asc`):
$ gpg -v --verify Qubes-R2-x86_64-DVD.iso.asc
gpg: armor header: Version: GnuPG v1
gpg: assuming signed data in `Qubes-R2-x86_64-DVD.iso'
gpg: Signature made Tue Sep 23 08:38:40 2014 UTC using RSA key ID 0A40E458
gpg: using PGP trust model
gpg: Good signature from "Qubes OS Release 2 Signing Key"
gpg: binary signature, digest algorithm SHA1
The Release 2 Signing Key ([`0x0A40E458`](https://keys.qubes-os.org/keys/qubes-release-2-signing-key.asc)) used to sign this ISO image should be signed by the Qubes Master Signing Key ([`0x36879494`](https://keys.qubes-os.org/keys/qubes-master-signing-key.asc)):
$ gpg --list-sig 0A40E458
pub 4096R/0A40E458 2012-11-15
uid Qubes OS Release 2 Signing Key
sig 36879494 2012-11-15 Qubes Master Signing Key
sig 3 0A40E458 2012-11-15 Qubes OS Release 2 Signing Key
Having problems verifying the ISO images? Make sure you have the corresponding release signing key and see this thread:
[https://groups.google.com/group/qubes-devel/browse\_thread/thread/4bdec1cd19509b38/9f8e219c41e1b232](https://groups.google.com/group/qubes-devel/browse_thread/thread/4bdec1cd19509b38/9f8e219c41e1b232)
Verifying Digests
-----------------
Each ISO is accompanied by a plain text file ending in `.DIGESTS`. This file contains the output of running several different crytographic hash functions on the ISO in order to obtain alphanumeric outputs known as "digests." For example, `Qubes-R2-x86_64-DVD.iso` is accompanied by `Qubes-R2-x86_64-DVD.iso.DIGESTS` which has the following content:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
6f6ff24f2edec3a7607671001e694d8e *Qubes-R2-x86_64-DVD.iso
0344e04a98b741c311936f3e2bb67fcebfc2be08 *Qubes-R2-x86_64-DVD.iso
1fa056b73d8e2e93acdf3dcaface2515d61335e723d1d7d338241209119c10a3 *Qubes-R2-x86_64-DVD.iso
a49ff19c1ad8c51a50198ac51670cf7c71972b437fa59f2e9fc9432cce76f4529f10de1d576ac777cdd49b9325eb2f32347fd13e0f9b04f823a73e84c6ddd772 *Qubes-R2-x86_64-DVD.iso
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCAAGBQJVvUfGAAoJEAxzudQKQORYhj0P/1TTtDn0WtlfwvSOQ5m3ybeT
CiEv/wWZmZR2hfTOs1chlwt5PZFUCkAk6hbr7+AbJU3HurnmyK97ORtak0WcuBiO
3MWKGiDaBGjKfYcv7YZWDcMRCjN69I4gq7lhXB2JC5pSnOkciD8xzSMAnyFz8Dnh
sHSGJIrOIeLhj0Jt90NGm2CKeQgKrbCGQWWqn/BRf40GXjkyGDSAj+Bsbnpn3LjE
kWOblX631PRi8eclD27/b5hsK/ur7RlpA0KKn7dJoTO2PikEZRoT7QgcIMxYWOja
GZhDi/5gWyttVmF1EszkwaYLAH3uqkZbgKHIsLwweTwXYxMqjobQ5dFkm0RCaXXg
wf/ayfyAIHCWYK0GvyHyAe7hs30UQ4Ssw0LDnnTsOwJYzxZpZqWhcg89EBMGdNgu
5sghcj97VHjDI/zpRyTOAi1+8ZoG1FMsvmnlpghojXPcFGM1nldKs2k1XfGHdVrH
ucJfhQilhsGo65EiN+v9VS6tz5dDtX5+NnkkpR5mOx1+xwUf4n+F6cWyIiLKY6Se
byIN0dPtErZpq47w6bhLZ3Dd/frReG8Egmr7yLAqGHKmuwvmEUA6w6a2VzWQy5G4
Smcj5kPHKWJ9SvAQHc7SoUmYqt2GEAKBi6CYb5Oeknf3vc4QUSPxF8KRiebUhTxc
ruycSbLkLklsDjfH0caD
=NVWj
-----END PGP SIGNATURE-----
Four digests have been computed for this ISO. The hash functions used, in order from top to bottom, are MD5, SHA1, SHA256, and SHA512. One way to verify that the ISO you downloaded matches any of these is by using `openssl` from the command line:
$ openssl dgst -md5 Qubes-R2-x86_64-DVD.iso
MD5(Qubes-R2-x86_64-DVD.iso)= 6f6ff24f2edec3a7607671001e694d8e
$ openssl dgst -sha1 Qubes-R2-x86_64-DVD.iso
SHA1(Qubes-R2-x86_64-DVD.iso)= 0344e04a98b741c311936f3e2bb67fcebfc2be08
$ openssl dgst -sha256 Qubes-R2-x86_64-DVD.iso
SHA256(Qubes-R2-x86_64-DVD.iso)= 1fa056b73d8e2e93acdf3dcaface2515d61335e723d1d7d338241209119c10a3
$ openssl dgst -sha512 Qubes-R2-x86_64-DVD.iso
SHA512(Qubes-R2-x86_64-DVD.iso)= a49ff19c1ad8c51a50198ac51670cf7c71972b437fa59f2e9fc9432cce76f4529f10de1d576ac777cdd49b9325eb2f32347fd13e0f9b04f823a73e84c6ddd772
(Notice that the outputs match the values from the `.DIGESTS` file.)
However, it is possible that an attacker replaced `Qubes-R2-x86_64-DVD.iso` with a malicious ISO, computed the hash values for that ISO, and replaced the values in `Qubes-R2-x86_64-DVD.iso.DIGESTS` with his own set of values. Therefore, ideally, we should also verify the authenticity of the listed hash values. Since `Qubes-R2-x86_64-DVD.iso.DIGESTS` is a clearsigned PGP file, we can use `gpg` to verify it from the command line:
$ gpg -v --verify Qubes-R2-x86_64-DVD.iso.DIGESTS
gpg: armor header: Hash: SHA256
gpg: armor header: Version: GnuPG v1
gpg: original file name=''
gpg: Signature made 2015-08-01T22:27:18 UTC using RSA key ID 0A40E458
gpg: using PGP trust model
gpg: Good signature from "Qubes OS Release 2 Signing Key"
gpg: textmode signature, digest algorithm SHA256
The signature is good. Assuming our copy of the `Qubes OS Release 2 Signing Key` is also authentic (see above), we can be confident that these hash values came from the Qubes devs.
Verifying Qubes Code
--------------------
Developers who fetch code from our Git server should always verify tags on the latest commit. Any commits that are not followed by a signed tag should not be trusted!
To verify a signature on a git tag, you can use:
$ git tag -v <tag name>