Current situation of *.pc: static linking is not supported (yet).
It has never supported, actually, by *-config.

There will be no full solution for this. However, the next release should in general work due to a 400ms delay we use after spawning the viewer. This is configurable; see rG7e5847da0f3d715cb59d05adcd9107b460b6411b.

I guess you are the only person who does it. But yeah. I agree that it should be fixed.

Actually the temp file is created but because the photo viewer is run as a detached process and gpg keeps on running, the temp file has been removed by gpg at the time the photo viewer tries to open it. Ooops. The correct behaviour would be to wait for the photo viewer to be finished. We use

That was obvious. rG6fc5df1e10129f3171d80cf731f310b9e8d97c26 fixes this.

When doing a "gpgsm --with-validation -k foo" (assuming you have a cert foo) gpgsm now goes into a loop and prints the certficates that match "foo" over and over again. I have not tested if it was caused by this change but I think it is likely.

I imported 39 certificate files at once with Kleopatra with about 700 certificates and it worked. Took a long time though so It would be nice if Kleopatra would show a progess indicator or some indication that the import is running. But this is a different issue.

The last lines that the process currently holding wrote in the log:

To reproduce this issue I started Kleopatra with an empty GNUPGHOME and imported 10 S/MIME certs at once (which spawns a gpgsm process each) with enabled logging.

As this update lists multiple issues and following fixes for them, maybe it was resolved by Microsoft?

Well, I deinstalled gpg 3.1.7 and reinstalled it. For some reason my two gnupg smart cards work fine, but my two Yubikeys cannot be detected anymore (no such device). But in the last weeks, they were deteced, only the switching between Yubikey and Smart Card made some trouble. That they cannot be recognized is new and makes real trouble. If you think it would maybe helpful, I can submit a scdaemon.log file by e-mail.

I've applied your patch with an additional comment to our master branch. Thanks!

gpg4win 3.1.6 is released which contains this fix.

Sorry, this did not make it into 3.1.6. But I'll definitely see about it for the next release. If it is an institutional / corporate issue you could also contract us through www.gnupg.com

In T4427#123774, @werner wrote:

Can you please run

gpg --debug ipc -vK

which will also start gpg-agent and print some diagnostics. You may want to redact the output. You can also run

From: aheinecke (Andre Heinecke)
Sent: Montag, 28. Januar 2019 19:25

fwiw. Your patch is beautiful in which it follows our coding style and
debug output. I'm confident that we will accept it but currently I have
to read up on Job's a bit.

Is there a way I could help you with this? This issue is hampering adoption
of GnuPG 2 here.

--

Jan Echternach

Trying to install the update manually (according to windows update my windows is fully updated) it says "This update is not meant for your computer" and aborts.

Can you please run

gpg --debug ipc -vK

which will also start gpg-agent and print some diagnostics. You may want to redact the output. You can also run

gpg-agent -v --daemon

which should also print some more info.

thanks for the report. Yes this is a known issue. This pinentry is so basic that it does not have dynamic layout as we don't include GUI libraries in the basic installer. For a better pinentry you can install Gpg4win.
In the future we are thinking about adding a pinentry based on the small "FLTK" toolkit, with dynamic layout.

I reviewed the multibyte handling in GnuPG and you are right, there is a general problem because we use ReadConsoleA and basically GetCommandLineA, so there is no way for multibyte input unless a parameter file is used. Output is also broken, but that is easier to fix iff the input case has been fixed.