Page MenuHome GnuPG

Key information loading is sometimes very slow. Suspected that the problem originated from gnupg.
Closed, ResolvedPublic


In the Windows environment, sometimes, when calling GpgMe API to create a Context, it will take a very long time to execute.
This problem is also reflected in Gpg4Win, manifested as the slow loading of key information.
gnupg seem to spend a lot of time to provide key information. Sometimes it even takes three minutes to open GpgFrontend or use Gpg4Win normally.
The frequency of this problem was found to be moderate in the past two months, and it usually appeared on the Windows platform.

gpg (GnuPG) 2.3.1
libgcrypt 1.9.3
gpgme 1.5.2-beta30



Event Timeline

Is there any change if you enable the keyboxd to store the keys? Put


into ~/.gnupg/common.conf.

Let me try, this problem sometimes happens, so it may takes some time to come to a conclusion.
But what I know is that after experiencing slow loading, it will not appear again when it is opened again later.

This could be caused by the periodic automatic update of the Web of Trust information. See --auto-check-trustdb in man gpg.

Put no-auto-check-trustdb in your gpg.conf to disable this (and create a cronjob or scheduled task which runs gpg --check-trustdb when it doesn't bother you, e.g. in the night).

Which reminds me that we should add a cronjob feature to dirmngr (which already does some background tasks) so that we can easiliy make use of --no-auto-check-trustdb on Windows.

Yes, I infer that the problem lies in the network-related modules. Because this waiting time is too long, it is probably not a problem of calculation and disk.


debug network,dns,ipc
log-file something

into dirmngr.conf to see what's going on.

debug network,dns,ipc
log-file C:\Users\Administrator\dirmgr.log

I wrote this in my dirmngr.conf. But i haven't found this .log file.

Did you restart dirmngr? ("gpgconf --kill dirmngr" so it will be started on demand).

Do you have write permissions to the directory; that is: Do you run gpg under the Administrator account?

###+++--- GPGConf ---+++###
keyserver hkps://
###+++--- GPGConf ---+++### 2021/5/8 14:18:58
# GPGConf edited this configuration file.
# It will disable options before this marked block, but it will
# never change anything below these lines.

debug network,dns,ipc
log-file P:\dirmgr.log

This is what my configuration file looks like now. I executed the restart command to confirm that the current user has write access to the directory. Is my path format wrong?

keyserver hkps:// is problematic.

The combination of hkps and :80 is strange and may not work because HTTP connections on port 80 are usually not TLS secured. But more problematic is that is dead, i.e. it does not resolve anymore to any servers. You need to use another keyserver. Try hkp:// or hkps:// instead, but note that for me the former is very slow (a simple --recv-keys of a single key takes 30+ seconds) and, again for me, the latter is even slower or doesn't answer at all.

I have recently been busy with the new features and mechanisms of the GpgFrontend project.

Now I located the API interface of GpgME corresponding to this problem.

gpgme_error_t gpgme_op_keylist_next(gpgme_ctx_t ctx, gpgme_key_t *r_key)

When this function is executed each round of the loop, it always takes a long time to return.

After several days of observation, after modifying the configuration file options , the problem has indeed been greatly alleviated.

keyserver hkps://
werner claimed this task.
werner edited projects, added gnupg, Keyserver, FAQ; removed Bug Report.

Okay, I close this as a keyserver infrastructure problem. Feel free tore-open if you get other infos.