![]() |
![]() |
![]() |
![]() | D Umstieg von anderen GnuPG Programmen | Inhalt |
Wir werden hier erläutern, wie Sie von anderen GnuPG basierten Programmen auf Gpg4win umsteigen können. Das Installationsprogramm erkennt einige dieser Programme und warnt Sie in diesem Fall.
Generell ist es ratsam, eine vorhandene Installation eines anderen GnuPG basierten Programms zu entfernen, bevor Gpg4win installiert wird. Es ist hier wichtig, die vorhandenen Schlüssel vorher zu sichern.
Der einzige sinnvolle Weg dies zu tun, ist unter Verwendung der im alten System vorhandenen Möglichkeiten. Suchen Sie nach einem Menüpunkt um die eigenen privaten (geheimen) Schlüssel zu sichern als auch nach einem Menüpunkt um alle vorhandenen öffentlichen Schlüssel und Zertifikate zu sichern. Sichern Sie diese dann in eine oder mehrere Dateien.
Sobald Sie Gpg4win installiert haben, prüfen Sie, ob Ihre alten Schlüssel bereits vorhanden sind. Sie können dies mit Kleopatra oder GPA machen. Sind die Schlüssel schon vorhanden, so entsprach das alte System bereits den neuen Konventionen zum Speicherort für die Schlüssel und Sie müssen nichts weiter unternehmen.
Wenn die alten Schlüssel nicht erscheinen, so importieren Sie diese einfach aus den erstellten Sicherungsdateien. Lesen Sie hierzu das Kapitel 19.
Falls das alte System GPA verwendet, so können Sie die dort vorhandene Backupmöglichkeit benutzen. Diese sollte sehr ähnlich zu der Funktion in der GPA Version aus Gpg4win sein.
Falls Sie keinen anderen Weg finden, Ihre alten Schlüssel wiederzufinden, so suchen Sie bitte mit den Bordmitteln von Windows nach Dateien mit den Namen secring.gpg und pubring.gpg und importieren diese beiden Dateien mittels Kleopatra10.
Es wird dingend empfohlen zunächst Gpg4win-1.1.3 zu deinstallieren bevor anschließend Gpg4win-2.0.0 installiert wird.
Das Problem bei einer Migration ohne Deinstallation von Gpg4win-1.1.3 ist folgende Sequenz:
1. Installation von Version X, inkl. Komponente K.
2. Installation von Version X+1, aber Komponente K wird diesmal deselektiert.
Effekt: Die alte Komponente von K bleibt installiert in der Version X.
3. Deinstallation von Version X+1.
Effekt: Die Komponente K in der Version X bleibt auf dem System verwaist zurück.
Mögliche Lösung: Installer ruft den aktuellen Deinstaller für die Komponente K auf, falls diese selektiert war, aber nicht mehr selektiert ist. Diese Lösung wäre allerdings ein erheblicher Programmier- und Testaufwand, da dies nicht von NSIS einfach unterstützt wird.
Alternative: Installierte Komponenten dürfen bei einem Update nicht deselektiert werden. Der Aufwand wäre vermutlich geringern. Allerdings keine perfekte Lösung. Grund: NSIS fehlt ein vollständiges Paketmanagement.
Diese Beschränkung ist in Gpg4win seit der ersten Version.
Anmerkung 1: Bei Sprung von 1.1.3 auf 2.0.0 tritt dieser Fall immer ein, da bestimmte Komponenten K nicht mehr existieren,also auf jeden Fall (automatisch) als deselektiert zu betrachten sind.
Anmerkung 2: Im Falle von MSI übernimmt Windows die Aufgabe, nicht mehr verwendeteKomponenten zu entfernen. Das bedeutet, dass der MSI installer in dem obigen Szenario korrekt ist (alte Komponente K in Version X ist nach Schritt 2 nicht mehr auf dem System vorhanden).
![]() |
![]() |
![]() |
![]() | D Umstieg von anderen GnuPG Programmen | Inhalt |