ich hatte bislang Gpg4win 3.1.10 im Einsatz. Diese Version habe ich auf bereits mehrmals neu installiert. Anschließend musste ich ledigllich die privaten Schlüssel wieder importieren.
Auf meinem neuen Gerät habe ich aber Gpg4win 3.1.13 installiert, dort konnte ich die privaten Schlüssel schon gar nicht importieren. Sie sollten immer bestätigt werden, indem man einen neuen Schlüssel anlegt, und wurden nicht als eigene Schlüssel erkannt.
Ich konnte sie nur als eigenen Schlüssel hinzufügen, indem ich ein Backup des Ordners in %appdata% einspielte, wenn ich Dateien verschlüsseln wollte oder Schlüssel erzeugen wollte, erhielt ich jedoch immer folgende Fehlermeldung:
„No such file or directory“
Im daraufhin aktivierten Log von GnuPG finden sich folgende Einträge:
2020-10-04 00:28:57 gpg[14040] DBG: chan_0x00000268 ← ERR 67141713 No such file or directory
2020-10-04 00:28:57 gpg[14040] agent_genkey failed: No such file or directory
2020-10-04 00:28:57 gpg[14040] key generation failed: No such file or directory
Wenn ich Gpg4win 3.1.13 deinstalliere und Gpg4win 3.1.10 installiere, funktioniert alles sofort und problemlos, wie ich gestern dann noch festgestellt habe, nachdem ich stundenlang versuchte, mit Gpg4win 3.1.13 eine wichtige E-Mail zu verschlüsseln.
Was kann das sein? Vielen Dank im Voraus für jede Unterstützung.
eine grobe Idee wäre, dass Dein Schlüssel sehr alt ist, und neuere GnuPG-Versionen
aus sicherheitsgründen schärfer geschaltet wurden.
Dafür probiere doch mal einen Import auf der Kommandozeile aus, also so was, wie
gpg -v --import DEIN-SCHLUESSEL
und lies Dir genau durch, was da an Diagnose Meldungen kommt.
etwa ein Jahr. Allerdings kann ich ja auch keine neuen Schlüssel erzeugen. Ich bin dann zurück auf die 3.1.10. Und jetzt läuft wieder alles. Aber früher oder später muss ich wohl updaten.
das liest sich erstmal seltsam, mir fällt direkt keine Änderung auf, welche das auslösen sollte. (Ich nehme an, Du verwendest bisher Kleopatra, richtig?)
Wie gesagt, probiere doch import und Schlüsselerzeugung mit der neuen Version
mal auf der Kommandozeile aus, z.B.
gpg -v --quick-gen-key TEST-NAME
da ich meine nun endlich wieder laufende Installation nicht zerschießen wollte, habe ich die Version 3.1.13 jetzt auf einem Testgerät installiert. Hier die Fehlermeldung bei der Variante über Kommandozeile:
gpg: agent_genkey failed: No such file or directory
In der Änderungshistorie zur Version 3.1.12 habe ich folgenen Hinweis gefunden: „Die Datei und URL verknüpfungen mit Kleopatra spalten nun korrekt Argumente und potentiell externe Daten wie Dateinamen und Such-Parameter. Dies verhindert ein Sicherheits-Problem mit dem Kleopatra dazu gebracht werden konnte eine Bibliothek von einem Pfad zu laden der durch eine nicht escapte URL übergeben wurde.“
Ich habe daraufhin einen neuen Benutzer angelegt, ohne Umlaute und ohne Leerzeichen, und siehe da: Kleopatra kann problemlos einen Schlüssel erzeugen. Aber nein, meinen Benutzer werde ich lediglich für Gpg4win nicht ändern, der bleibt so wie er ist.
Aber ist das vielleicht ein Ansatz für die Lösung?
ich hatte den Befehl jeweils 1:1 wie oben in deinem Beispiel eingegeben:
gpg -v --quick-gen-key TEST-NAME
Ob es funktioniert oder nicht scheint vom Benutzernamen abzuhängen. Mein Benutzername, und damit der Pfad zu %appdata%, enthält ein Sonderzeichen und ein Leerzeichen. Das ist sicherlich nicht optimal aber sorgt ansonsten für keine Probleme.
ich hatte mir einen neuen Benutzer angelegt und damit ging es dann problemlos. Dieses Verhalten konnte ich sowohl auf meinem Rechner als auch auf meinem Testsystem beobachten. Ich kann dir nur leider nicht sagen, ob das Leerzeichen oder der Umlaut dafür verantwortlich ist, das muss ich nachher noch testen.
Benutzer „Hans“: Schlüsselpaar erfolgreich erstellt
Benutzer „Hans Mustermann“: Schlüsselpaar erfolgreich erstellt
Benutzer „Hans Müstermann“: Schlüsselpaar kann nicht erstellt werden: No such file or directory
das Problem tritt bei mir auch beim Importieren eines geheimen Schlüssels auf. Es wird nicht nach der Passphrase gefragt. Die Beglaubigung geht dann auch nicht, da das Anlegen eines eigene Zertifikat auch nicht geht.
sofern bei Dir im Windows Pfad (Konto-Namen) Zeichen vorkommen, welche
nicht ASCII sind, beispielsweise Umlaute. Dann leidest Du unter dem gleichen Defekt.