Private key no longer exists after crash

[jarromie]

I am no longer able to encrypt/decrypt using the private keys available to me after the program crashed. When I Right click -> Show Key Details it now says at the bottom Primary Key Existence: Not Exists, and I am unable to find the private keys on my disk.

Crash happened after decrypting a simple message that was encrypted to my own key (a password I didn't want stored in plaintext). The decrypted text appeared in the text-box for a moment before program crashed. No error messages or popups were displayed. If there is a place for me to find & upload logs, please let me know.

[saturneric]

To troubleshoot, you can navigate to the Settings and select the specified button to locate the logs directory. GpgFrontend does not alter your key data directly; instead, it interfaces with the GpgME library, which is developed and maintained by the GnuPG group. Therefore, it is unexpected for such an issue to occur.

[jarromie]

On my machine (Windows), it only has a button where you described to delete all logs; nothing to open the directory.

The app is installed via Microsoft Store, if that helps. I have no idea where the application's data winds up at, it's not in Program Files like I would expect a native app to install to, and I didn't see it in %APPDATA% either.

[jarromie]

After another couple restarts during my search for the logs button, now even all of my public keys, besides for one (which had already lost the private key), have also disappeared from the side menu and the Manage Keys window.

[saturneric]

The version of this application currently available on the Microsoft Store is v2.1.1. However, you can access the latest portable version (v2.1.2) by downloading it from HERE. Please try this version to see if the issue persists.

Exactly: GpgFrontend-2.1.2-qt6-windows-x86_64-portable.zip

[jarromie]

This issue seems to be fixed using the portable version. Before closing the issue, where can I find my private key storage, so that I can back them up? The application will not allow me to export my secret keys.

[saturneric]

Thank you for bringing this to my attention. I'm pleased to inform you that GpgFrontend in the MS Store has been updated to version 2.1.2. I recommend updating to this latest version, which should address the issue you've encountered with exporting your secret keys.

Regarding your question about backing up your private keys, GnuPG stores the key database in the .gnupg folder located in your user's home directory. On Windows, this typically corresponds to C:\Users\<YourUserName>\.gnupg. You can manually copy this folder to another location to back up your keys.

Additionally, GpgFrontend offers a KeyPackage feature, which I can use to easily backup and restore your keys. This feature is designed to simplify the process of managing your keys, especially when transitioning between different machines or ensuring that your keys are safely stored.

[jarromie]

There is no .gnupg folder in my C:\Users\admin\ folder. I will test and see if exporting private keys is fixed, and report back momentarily.

[saturneric]

There is no .gnupg folder in my C:\Users\admin\ folder. I will test and see if exporting private keys is fixed, and report back momentarily.

My fault. On Windows, all GPG keys are stored in the "keyring", which is at ~/. gnupg or%AppData%/gnupg . You can check %AppData%/gnupg.

[jarromie]

After a PC restart (assuming this restarted with the gnupg service), the keys are visible again in GpgFrontend. Upon clicking Show Key Details the first few times, it still said Primary Key Existence: Not Exists, but allowed me to decrypt messages. After opening the window a few more times, it decided it now Exists, but exporting keys in the client still did not seem to work.

Upon clicking Export Private Key -> Export Full Secret Key, it prompts me with the window pictured below, and then after pressing OK, it asks for a password. Regardless of whether I enter the correct or incorrect password, nothing seems to happen.

Aside from that, I am still searching for my keyring; there is no folder located at %APPDATA%\gnupg or %LOCALAPPDATA%\gnupg. Based on the documentation, the --homedir variable can be used to set a custom home environment for gnupg, where the keyring should be stored, which otherwise defaults to the environmental variable GNUPGHOME (which was not set on my system), or the registry entry HKCU\Software\GNU\GnuPG:HomeDir., which also does not exist on my system (there is nothing about GNU anywhere in HKCU\Software\).

Finally, after much searching, I found the gnupg folder, as well as the keyrings, packaged inside of the application data folder for GpgFrontend, which was painfully difficult to locate and obnoxiously named (due to having installed via Microsoft Store --- I have no clue why they insist on this god awful directory naming convention). If you're wondering, the location: %APPDATA%\Local\Packages\15599Saturneric.GpgFrontend_cmzh4yccza0qa\LocalCache\Roaming\gnupg\

Anyways, I suppose you could close this issue and create a new one in relation to the issues exporting private keys, or we can continue to debug here; I'm happy to help, if you don't have access to a Windows machine.

[saturneric]

Thank you very much for bringing these issues to our attention. It seems that the challenges you've encountered might be related to the sandboxing mechanisms employed by the Windows platform, especially for applications distributed through the Microsoft Store. This sandboxing can affect how applications access, store, and manage files, leading to the behavior you've experienced.

I appreciate your detailed account, which has highlighted these issues that I previously hadn't encountered, as my development work has been primarily focused on the macOS platform. Your input is invaluable, and I will conduct a thorough review and verification process to better understand these phenomena and work towards a resolution.

[saturneric]

I have recorded all issues mentioned here and will continue to work on them. So I 'm now planing to close this issue cause the main issue had allready been solved.