Git-Mirrors/qubes-doc
1
0
Fork 0
mirror of https://github.com/QubesOS/qubes-doc.git synced 2025-02-26 09:41:13 -05:00
Code Issues Packages Projects Releases Wiki Activity

UpgradeToR2B1 changed

Browse Source 
Formatting
This commit is contained in:
Joanna Rutkowska 2012-12-09 18:30:38 +00:00
parent efad43dae5
commit 95edbf1cea
1 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
UpgradeToR2B1.md
View File

@ -29,18 +29,18 @@ By default, in Qubes R1, there is only one Template VM, however users are free t
sudo yum update 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} ``` {.wiki}
Importing GPG key 0x0A40E458: Importing GPG key 0x0A40E458:
Userid : "Qubes OS Release 2 Signing Key" Userid : "Qubes OS Release 2 Signing Key"
Fingerprint: 3f01 def4 9719 158e f862 66f8 0c73 b9d4 0a40 e458 Fingerprint: 3f01 def4 9719 158e f862 66f8 0c73 b9d4 0a40 e458
Package : qubes-upgrade-vm-1.0-1.fc17.x86_64 (@qubes-vm-current) 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 From : /etc/pki/rpm-gpg/RPM-GPG-KEY-upgrade-qubes-2-primary
Is this ok [y/N]: 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 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). - 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).