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

UpgradeToR2B1 changed

Browse Source 
Note on accepting the R2 key
This commit is contained in:
Joanna Rutkowska 2012-12-09 18:20:52 +00:00
parent 4fe096f0d6
commit 57809322f4
1 changed files with 17 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
UpgradeToR2B1.md
View File

@ -29,5 +29,21 @@ By default, in Qubes R1, there is only one Template VM, however users are free t
sudo yum update
```
4. Shut down the VM.
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]:
```
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:
- 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.