Note that for vsd we also need to change our default configuration file. The new "none" value provides a better error message than the old default of assuming that the AD carries the keyserver (which it does not in practise).

What I would like to be able to do would be:

Why do you need an integer - for real random this must be larger than 64 bits and then you have problems to to find a suitable type for a variable.

Not easy do decide whether something is a PIN or a PUK and we will need to check a lot of places. So, not now.

Turning this into a feature request: We should create P12 files using AES instead of 3DES

The MSI Package though is a 64 bit MSI Package. For 32 Bit Windows we would need to ship a different MSI Package. (Which we actually have build support for because I thought that was neccessary even in 2020)

No, everything in Gpg4win is 32 bit, except for gpgol, gpgex and gpgme, libgpg-error and libassuan. Which are addionally installed under bin_64. But for the whole KDE stack it should easily be switchable. The KDE Windows project regularly builds them as 64bit applications. Basically we would then need to invert the logic and use the 64 bit compiler as the main compiler and the 32 bit compiler as the _ex compiler for gpgol and gpgme.

Kleopatra is a 64 bit application, right? For GnuPG we are working on 64 bit support for Windows. This is planned for 2.6. problems are how to represent sockets, file descriptors, streams and so on. Regarding the time interface, we should have everything ready in the GPGME<->GnuPG interface. In GPGME we need to check that we don't use int instead of time_t, though. When that has been done/fixed we could use a 64 bit gpgme and kleopatra along with the 32 but gnupg. Might be easier for approval reasons.

Mh, since there are no 32bit Versions of Windows sold for quite some years now maybe we should consider just going full 64bit with everything to solve this? Or is this a stupid suggestion?

It turned out that we need to fix this for use by Kleopatra on Windows.

Sorry, I only now noticed that you used the --export-secret-ssh-key. Unfortunately commit
rGafe5fcda52e88438c7a7278117b2e03f510a9c1c states in the comment:
"Due to time constraints the code is not yet ready." Let's turn this into a feature request.

It looks to me like it's marginally more common to *not* use the lib prefix for pkgconfig files:

I think that might have been some idea we had before we added --require-compliance and proper display of non compliant signatures in KMail and Kleopatra and wanted to ensure that non compliant signatures are not "Green".
But since this is not a regression we might even consider not changing this in 2.2 anymore but instead do some relaxation how we treat non compliant signatures both for creation and verification in 2.4 I see T6644 as related.

Thinking about this, I don't think offering the information exportable or not will help users much. The concept of "exportable or local signatures" should be a technical details that we should not require our users to understand. The intention of defaulting to local signatures and hiding the export under "Advanced" was to give users a way to basically use "Trust on first use" to certify a key for their personal use and honestly without checking the fingerprint. Even though they "should" not do that. If this makes sense for GnuPG VSD is arguable since we have now better spelled it out what "certification trust (ownertrust)" means. So maybe exportable signatures should become the default for GnuPG VS-D? With the classical SKS style keyservers in Gpg4win I tend to keep local signatures the default.

I am reopening this at least for testing as we have reports that another client is facing the issue with recent versions and also with verified mails .

assuan_sock_accept approach is taken in gnupg master.

gniibe/t6606 patches are all pushed into master.

But shouldn't we then rather rename the shortcut of Kleopatra to: GnuPG VS-Desktop - Kleopatra ? That would make it discoverable under both names.

Our sales team gets the support calls and they have to explain that really often.

werner I strongly disagree here. There is no need for this for our software on Windows and that is definitely not the Windows way, esp. with our current feature set. Do you really think a user wants to start "GnuPG VS-Desktop" to then have a selection between Okular, Outlook, and Kleopatra? That is not how this works at all. Definitely not High priority for us if you think Kleopatra is too hard to discover then we could add another start menu entry for Kleopatra called "GnuPG VS-Desktop" but a starter that only offers to switch between Okular and Kleopatra currently does _not_ have high priority, For windows this is solved with the windows registry, If you want to make Okular - GnuPG Edition your default PDF reader you can, similarly for Kleopatra and please also keep in mind that a user wants to "Encrypt" or "Decrypt" a file. And does not necessarily care about Kleopatra.

FWIW, we also need this for Windows. ppl often ask what to do after they installed VSD because they can't find a program. Thus a menu ala Kontact is the way to go. It would be linked directly from a GnUPG Desktop entry from Windows. We can even keep the old Kleopatra becuase it does not harm. Whether the "menu" is a container window or a detached windows can be decided by the user, like GIMP and other tools do this.

I suppose you have read https://docs.appimage.org/user-guide/run-appimages.html#integrating-appimages-into-the-desktop, even though I think those two helpers don't do what you want and, on top, they are Linux-specific.

I am pretty sure what I want to do here. There is no way around .desktop files if we want to have proper linux integration. Otherwise you cannot for example have okular gnupg in the "start with" menu. It is something like the Windows registry integration. Or make KMail with GnuPG Desktop your default Mail client etc.

Applied: rGb8c5d99406c9: gpg,agent,kbx,sm,scd,tpm2d,g13: Use assuan_control.

In T6606#173044, @gniibe wrote:

More care is needed to be perfect; There are places in GnuPG where assuan_sock_connect may be used before syscall clamp set up (after the first assuan_sock_bind failure).

Dear Werner, have you had any toughts about this ?

Currently, Kleopatra cannot do anything about this. get_passphrase in protect-tool.c asks those questions and doesn't support a way to give the user more context (e.g. by providing the file name). Once gpg-agent allows giving context, Kleopatra can add for example the file name to the data to import.

Applied to master.

yes, one down, two to go...

Meanwhile the AppImage (same binaries as the current Gpg4win version) can be found here among the binary releases: https://gnupg.org/download/index.html

I realized again how bad the current implementation is last week when Alexander managed to send a mail to me encrypted with a completely unrelated key.
a) It was not clear to him that he encrypted to a totally different key because it only displays the keyid
b) He somehow managed to store that key for me in the addressbook
c) He again selected something like "always encrypt to this user" in the dialog without realizing the consequences. This created a contact for me in his personal address book (invisible to him because he said he does not use the addressbook and in there all sources were unselcted) which had the wrong keyid (again only the fingerprint there) and the setting "always encrypt to this user"

Applied the changes for libassuan T6487 into gniibe/t6606.

Pushed the change in gniibe/t6606 branch.

Another approach would be:

• Use assuan_sock_accept which has consistent API with gnupg_fd_t

On 64-bit Windows, the situation now is:

Use of FD2INT for the first argument of select is semantically not good. It's the number of file descriptor. When we use FD2INT here, the type is converted to 64-bit integer, then implicitly demoted to 32-bit integer. We need new macro, say, FD2NUM to convert FD into 32-bit integer.
<--- done in: rGea1935252e28: commond: Introduce FD2NUM to express conversion to number of fds.

Here is a test program for 64-bit Windows to see how cast works:

#include <stdint.h>
#include <stdio.h>