From 95edbf1cead12769b0fdb85af46499ef1c22b048 Mon Sep 17 00:00:00 2001 From: Joanna Rutkowska Date: Sun, 9 Dec 2012 18:30:38 +0000 Subject: [PATCH] UpgradeToR2B1 changed Formatting --- UpgradeToR2B1.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/UpgradeToR2B1.md b/UpgradeToR2B1.md index 2d18d35d..feaf8a7d 100644 --- a/UpgradeToR2B1.md +++ b/UpgradeToR2B1.md @@ -29,18 +29,18 @@ By default, in Qubes R1, there is only one Template VM, however users are free t sudo yum update ``` -The installer (yum) will prompt to accept the new Qubes R2 signing key: + The installer (yum) will prompt to accept the new Qubes R2 signing key: -``` {.wiki} -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]: -``` + ``` {.wiki} + 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 is 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 ways for such key to make it to your Template VM's filesystem: + 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).