Just started wondering how much of this slow down is because of MingW libc not having very well optimized memcpy/memmove/memchr/strlen/etc. Is there profiling tools like 'perf' on Linux that could be used for Windows builds?

For Windows things are actually more complicate. It seems to be common practise of sysadmins to provide PAC files which are used to map URLs to proxys and to decide whether a proxy is to be used at all. Fortunately Windows provides an API to find the proxy for a specific URL. We should use this.

ack

@werner: What do you mean by "We have a fix for now"? Are you referring to @gniibe's patch?

We have a fix for now and thus I lower the priority. Given that EasyPG mimics the GPGME API we should here also use another pipe to convey the passphrase (e.g. for symmetric encryption).

Thank you for the response, @werner! (original reporter here)

BTW. you should use gpg --quick-set-expire FINGERPRINT 5y this is easier for scripting. Using
--export-options no-export-clean should keep the old signatures.

gpg only uses the latest self-signatures and ignores old one. Thus I do not understand your problem.

We should not backport this to 2.2; better update to the current stable version (2.4)

Using Ubuntu, it's GnuPG 2.2 (which doesn't have the fix of T4585). Without the fix, killing gpg (by CTRL-C) causes problematic situation where pinentry remains asking.
That's because gpg-agent and pinentry don't know the frontend side has been killed. T4585 introduced a watching thread into gpg-agent, so that it can correctly detect lost of frontend.

Hi @gniibe - thanks for your fix.

Pushed the fix for SIGINT handling of pinentry-tty and pinentry-curses by: rPa6f63fe37dbf: tty,curses: Upon SIGINT, let pinentry exit gracefully.
This fix should improve the situation.

Thank you for the report.
I found a bug in pinentry-curses and pinentry-tty for handling SIGINT. I am going to fix this.

In T6085#162923, @ikloecker wrote:

In T6085#162918, @ebo wrote:

well, when creating openPGP keys with kleopatra I did not see any hints. I do not think that the issue would be vaild for password based encryption. There the common usecase is autogeneration, anyway

Autogeneration isn't viable if an organization has stupid password constraints that the autogenerated passwords do not satisfy. In particular, the autogenerated passwords do not contain any non-alphanumeric characters, but many password policies require such a character.

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.

Applied to 2.4.

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

@jukivili Good to know.