These are great news. Thank you!

Pushed the change to libgpg-error and libgcrypt (1.9 and master).
Let us see if there are any problem(s) for that, I will apply it to other libraries when it will be found no problem.

Thank you for the information.
For the record, I put the link to the email submitted:
https://lists.gnu.org/archive/html/libtool-patches/2020-06/msg00001.html

Could anyone please be so kind to confirm me if when 'gpg4win-3.1.16.exe' setup completes without any error the new folders where Gpg4win and GnuPG commands can be found are prepended (so inserted at beginning) or appended (so added at the end) of already existing %PATH%) ?
I'm asking this to properly ensure that my new manually modified configuration %PATH% is indeed equivalent to an original configured one (and so far I've assumed that my manual changes should have been prepended %ProgramFiles(x86)%\Gpg4win\bin;%ProgramFiles(x86)%\GnuPG\bin;%PATH% but doing this was probably only my choice because such changes were just faster to do).

@grv87, thanks for clarification (and very interesting side thread reference you gave, indeed, also because it also gives you an idea of how system environment changes during OS startup). I precisely see your point and that's also why I said "create 2 new system variables".
I've not said this very explicitly before but for that I also meant to just create them during Gpg4win setup. When it is run, I assume we can also say that OS system environment is already in place and %PATH% should already be stable enough to consider that as a good starting point to add things. So once you can really do that (I mean add 2 new system variables), and then also ensure they're created correctly, then I can also assume that then starting to use them to update %PATH% system variable might be fine too.

@swimmerm, my 2nd comment offers some solutions for you and other users coming here with the same problem with their PATH. It should be done on user side. I don't offer to implement this in Gpg4Win installer.

@grv87 OK, many thanks indeed for confirming all this.
About your 1st comment: that's just right why I asked about it. Regarding md5sum and pinentry both must be the reason why now they decided to also add 1st path into environment while in older version wasn't there. Main issue is that because of the quite generic 'PATH env variable too big' error so far we can only assume 2047 was indeed maximum size for %PATH% Gpg4win developers have been expecting so far, while after that change from March 2012 QFE fix a definitive fix to implement in setup and rest of Gpg4win involved code will just be to enhance that maximum allowed path size to 4095 characters (BTW also checking anyway for size of %PATH% already active before setup will continue with new %PATH% changes is probably best option too).
About your 2nd & 3rd comments: thanks for those useful references. Would probably be quicker to implement, but it's still again true that maximum size expected for %PATH% will still need to increment from (likely) 2047 to 4095, plus also what you said about something "for expert users only". And even then inside README.txt (that now corresponds to %ProgramFiles(x86)%\GnuPG\README.txt or %ProgramFiles(x86)%\Gpg4win\share\gpg4win\README.en.txt or %ProgramFiles(x86)%\Gpg4win\share\gpg4win\README.it.txt) there should be at least 1 note about suggested way to do things. Problem is that because of above (March 2012) MS KB article statements '... If an existing value contains more than 2047 characters, you cannot enter additional data. However, you can delete the characters that are displayed. ...' whenever %PATH% size is over that value (always true for me even after manual %PATH% downsizing I had to do) OS UI will be of no or very little help (and by very little I intend that to overcome that OS UI limitation expert users with Admin privileges will 1st need to manually modify Path value into Registry, let's say by adding at least 1 or 2 ";" really unneeded, then just use OS UI to modify %PATH% system variable by deleting those ";" unneeded (i.e. %ProgramFiles(x86)%\Gpg4win\bin;;%ProgramFiles(x86)%\GnuPG\bin;;) and then once removed confirm with OK twice, and voilà it's done).
(P.S. BTW I just checked that so it really works fine for all applications started after that change ;-D so this might probably be best known option to document inside that README.txt.
N.B. JFYI in the past I also tried to use SETX from command line, and so I discovered that it only has a 1024 maximum characters limit after which it will just truncate any expected change that is saved anyway into selected system variable).
Otherwise, another possible approach variation but unsure if needing more coding would be to create 2 new system variables (let's say Gpg4win and GnuPG) and then add both %Gpg4win%;%GnuPG%; in front of existing %PATH% while installing, but obviously still after enhancing maximum allowed PATH size to 4095.

On the issue, I think there are several possible solutions, better than current:

1. Warn user that PATH is too big and tell him which dirs should be added manually
2. Warn user that PATH is too big but still modify it. He has to modify it with something else than UI, so it's for expert users only
3. Ask user to choose between 1 or 2

BTW, there are known solutions to manage with PATH overgrowth.

@swimmerm, look at the files installed in both dirs.
There is no gpg in %ProgramFiles(x86)%\Gpg4win\bin, it is in %ProgramFiles(x86)%\GnuPG\bin.
On the other side, md5sum and pinentry are in the first one.
So, I believe you (and I) should add both dirs to the path.

Thanks. This looks good to me.

It parses wrongly. I think that we need a fix like:

diff --git a/g10/mainproc.c b/g10/mainproc.c
index 1ee5b9a6e..7f51b263b 100644
--- a/g10/mainproc.c
+++ b/g10/mainproc.c
@@ -725,6 +725,9 @@ proc_encrypted (CTX c, PACKET *pkt)

Thank you for pointing out. Since hmac256.{c,h} can be used by others, I think that it is better to keep those two files, instead of merging it into one.

That looks all pretty standard. I don't know what's going on. I need to be able to replicate it here.

Hello Mr. Koch,

Patch has been applied to Kleopatra. See T5619: Kleopatra does not create the UI-Server socket in the socketdir.

Somehow this looks like a bug in gettext or our usage of it. It seems as if the last characters of strings appended to translated texts are sometimes doubled as if the string was built twice, once with 1 or 2 more characters and then overwritten with a slightly shorter string. Very strange.

Sorry, I am not abale to replicate this with standard version of gpg. Hwoever, the portable version only changes the directories and nothing at the output code paths. THus I really wonder what's going on here. Note that the spaces used to indent the "mittels ..." are also missing.

Key verification: Double Number in the end of fingerprint:
The same problem, as with the portable version.

Oh, you are right, it's not upstream. It's actually applied to Homebrew (https://brew.sh/) libtool formula which is where I originally got libtool.m4, see:

Sorry about that, I forgot to add GCC. I updated the original post with the needed information.

Ah well, Kleopatra has a GUI to set the keyserver - that is probably easier to use.

The keyserver network has been shutdown a couple of months ago. We can't do anything about it. The default in newer gpg versions has changed; you may put

Okay.

I tried to generate a tarball from master and I failed to build the hmac256 binary because the hmac256.h was not packaged into the dist tarball in master. If hmac256 should be standalone binary, I propose it should not need have a separate header file:

Alternative patch for Kleopatra:

diff --git a/src/uiserver/uiserver.cpp b/src/uiserver/uiserver.cpp
index d9746f0b..ab4d2ca7 100644
--- a/src/uiserver/uiserver.cpp
+++ b/src/uiserver/uiserver.cpp
@@ -23,6 +23,8 @@
 #include "kleopatra_debug.h"
 #include <KLocalizedString>

Not from understanding. libkleo adds high-level functionality that's useful for KDE applications, but out-of-scope for gpgme and its C++/Qt wrappers gpgme++ and qgpgme. I would use GpgME::dirInfo() directly in Kleopatra. It would make sense to add an overload of GpgME::dirInfo() that takes an enum, so that one does not have to use the low-level string names in Kleopatra. The downside is that a string-based interface can be extended easily. OTOH, deprecating values of a string-based interface is hard and after removing it the compiler won't complain.

We want to deprecate the whole UI-Server thing and thus I considered it better to provide the generic socket dir instead of adding support in libkleo for the uiserver socket. For the time being, doing this in Kleopatra sounds better to me. From my understanding. libkleo shall be an interface to gpgme++, right?

gpgme_get_dirinfo does already have support for "uiserver-socket" since about 7 years. I don't think a separate "socketdir" which requires a brand new gpgme makes much sense.

Since the migration to a new machine with lots of config changes this spring the redirect rules for bugs.gnupg.org were not properly adjusted and when running into an error, it seems that the admin back then ignored the problem and simply removed bugs.gnupg.org from dehydrated's list of domains. Thanks again for reporting. Should now work again.

Sorry for your troubles but we need to protect against spam - a tracker flooded with spam is useless.

Sorry, I don't know which software has version 12.0.0 and which git master this is. In case this is stock libksba, please tell us at least the last commit id. Note that we in general do not support arbitrary versions from the repos but only released versions .

For Kleopatra this patch

It will be useful to have support in libkleo:

While I'm still waiting for anyone to possibly answer my last 'Sat, Sep 18, 6:29 PM' question I've also added there the explanation behind that question... :-)

Thank you.

I see your point. I'd like to locate/identify where the change comes from.
I think that what you refer by "new libtool.m4" is actually macOS local change (I mean, not from libtool upstream, AFAIK).
Could you please point out the source of the change?

Please see T5587

That would work, however we might hit this issue with a new macOS release. Would it make more sense to update to what the new libtool.m4 is doing? Linker flags are the same, it only changes the way they detect macOS versions:

Here is James' writeup on the use https://gnupg.org/blog/20210315-using-tpm-with-gnupg-2.3.html . For more details please consult the mailing lists and the commit messages.

I'm not really sure which version it worked with earlier. This yubikey setup is quite old now, and I've not signed keys recently. I think the last I signed were at least 2 yrs back, hence the very vague allusion to the setup working previously. Apologies, no definite answer there.

Tsss, requires to allow JS for Google.

I think that scenario with TPM emulation would be more generic.
What needs to be done to have TPM emulation? Can you point on some doc about that?

Ich you do not have a working TPM or emulation but the tpm libraries installed run configure with the option

--disable-tpm2d

LTO warnings are trashing LTO optimised binaries and that is definitelly gnupg code issiues.
Just check each two places where rowtines are defined and declared in header files.

Just FYI, see also how GnuTLS has proposed to implement the service indicator:
https://gitlab.com/gnutls/gnutls/-/merge_requests/1465

That does indeed not look like something which could introduce a regression.