2.1.4 minor issues and observations / Windows

[Achim16]

Thanks a lot for the update 2.1.4 and the many improvements

However some observations re both Win QT5 and QT6, as they are more cosmetic I post them in one go

• Zipped QT5 version lacks "portable" in the filename and portable.txt in the archive. What is the reason ?
• QT5 version lacks menu Help/GnuPG
• QT5 version in Help/About lacks tabs "Gnupg" and "Update"
• QT6 version - on a German OS with GPGfrontend language settings AE the "about" menu displays a funny mix of languages on tabs and column headers, see image
• The enhanced "manage keys" (thanks) does not remember changes in column width (eg KEY ID) when closing and re-opening this dialog.
• PaperKey support - how can I make use of " allowing export of a printable and storable key format" ?

Generally, do you for Windows recommend usage of QT5 and QT6. I recognize the need on Linux for separate versions, not sure of the reasons for Windows to do so.

[saturneric]

Thank you for your detailed observations regarding both the Win QT5 and QT6 versions of our application. Your feedback is crucial, and I have also noticed some of the issues you've mentioned (and even more on my end).

I have spent the last evening addressing some of the defects discovered. Specifically, I have fixed the third and fourth issues you mentioned. Although these seem like simple problems, they involved more complex thread synchronization principles to resolve.

Regarding the last issue about the "manage keys" dialog not remembering changes in column width (e.g., KEY ID) upon closing and reopening, I consider this a minor defect. Therefore, I do not plan to address it immediately, but I will include a fix in a future version.

As for the Qt5-related issues, I do not recommend continuing with the Qt5 version. This version has entered the late maintenance stage. As you noticed, it lacks the "Update" tab because Qt5 no longer includes the modules. The "Software Update" and "GnuPG Information Collection" features have been fully modularized since version 2.1.4. This mechanism allows users to trim features after release and enables the main program to focus more on its core functionalities.

[saturneric]

Moreover, about the PaperKey feature, you can find the export option near the operation for exporting private keys. Additionally, you can locate the import option in the public key operation menu. This is particularly useful for simulating a scenario where the private key is lost and only the public key is available.

Through my testing, I have found that this feature does not work with some of the newer algorithms. I will continue to improve this in future versions.

[Achim16]

Thanks. On Paperkey, for me also RSA import does not work. I tried the following, generate a 2048 RSA test key, export public,secret, and paperkey separately. Then deleted the entire key and inported just the pub. Went to the option paperkey import, which returns an error. On a more abstract level, the question to me is whether Paperkey import should be made available not only if a public key still exists, but in the main import menu. To my understanding public keys derive from private keys - importing a secret key in the 'normal way' at least always also generated a corresponding public key, i.e a full key pair.

A general remark on GPGFrontend. There were a lot of fantastic tools for GPG Legacy in particular for Windows but for many years not for GPG 2 except for GPGWin which is way too over bloated with Kleopatra etc and WinGPG which was not further developed. Your tool therefore closes a gap on for lightweight GPG 2 GUIs.

[saturneric]

I currently work on both Debian and macOS, and while the PaperKey feature should work on Linux, it seems to encounter issues with some advanced ECC curves, as I've tried and failed to get it working. I haven't yet fully tested this on Windows, so it's not surprising if it doesn't work there. This is because I directly ported the code from the author's repository with minimal changes, and my testing has been primarily on Debian.

[saturneric]

This illustrates the challenge of cross-platform software development, where ensuring compatibility across three platforms is a constant effort. Just getting the software to compile and run correctly on each platform consumed a significant amount of my time. Comprehensive testing on every platform is even more demanding. Therefore, I rely heavily on feedback from users on different platforms to track and fix these issues, gradually stabilizing the features over time. I am also open to suggestions for improvements, as these often highlight aspects I hadn't considered and can make the software more user-friendly. I am willing to dedicate time to implement new features requested in such feedback.

Regarding the broader context: thank you for your encouragement; it truly fuels my motivation. During my exploration and learning of GnuPG, I encountered the same issues with existing software being either poorly maintained or overly complex. At one point, I doubted whether most of GnuPG's functionality could only be accessed via the command line, until I discovered gpg4usb. It met nearly all my expectations for a GPG client, but unfortunately, it was no longer maintained. I realized others might face the same problem, so I decided to continue maintaining the gpg4usb project, making it more universal and cross-platform to benefit more users. However, this also meant cutting ties with the old GPG 1.4 compatibility.

[saturneric]

On a more abstract level, the question to me is whether Paperkey import should be made available not only if a public key still exists, but in the main import menu. To my understanding public keys derive from private keys - importing a secret key in the 'normal way' at least always also generated a corresponding public key, i.e a full key pair.

You are correct that public keys are derived from private keys. When importing a secret key in the 'normal way', a corresponding public key is always generated, resulting in a full key pair.

However, according to the PaperKey documentation, it does not store the entire key. To facilitate storage, PaperKey only contains the essential information:

Paperkey extracts just those secret bytes and prints them in an easily handled format. To reconstruct, you re-enter those bytes (whether by hand or via OCR) and paperkey uses them to transform your existing public key into a secret key.

This means PaperKey does not include the public key information. Instead, it relies on the public key and the secret bits it stores to reconstruct the full key.

[Achim16]

Thanks for your notes - an update from my side on 2.1.4.3 you kindly released,

• on a language change the below menu item does not change on the automatic restart (QT6/Windows) , but only next time you start the application again, but this is cosmetic only , so the issue is basically sorted, thanks.

• I have a specific problem with Windows/QT5 2.1.4.3, this crashed already when launching on Windows 10 / 222H-4651. Will try if I can reproduce this behaviour on other machines and OS

[saturneric]

• I have a specific problem with Windows/QT5 2.1.4.3, this crashed already when launching on Windows 10 / 222H-4651. Will try if I can reproduce this behaviour on other machines and OS

I will test this as well, too frequent crashes are indeed serious flaws. If you have thread stack information related to software crashes, you can share it with me, it helps to localize the problem.

[saturneric]

I think this issue has fulfilled its mission, the confirmed issue was fixed in v2.1.5.