I'll push some patches for proposal 1.

The thing is that I don't see this bug with verbose logging enabled. So we need to do more code starring or instrument the code

gpg-connect-agent is used by gpgconf to make things easier. Adding socket playing games is the opposite of simplifying things.

Is there a more detailed logging that i can switch on? Perhaps i can help you to get diagnostic files. Nearly every day i notice this bug. In the log (with "verbose" in gpg-agent.conf) are the same entries i already posted.

the UP arrow can be trick ... it reminds me the whole thing about Apollo Missions ... the navigation system;

For what is worth I think sanitize_regexp was programmed while reading 4880 because the RFC allows backslash + any character (section 8: Regular Expressions):

It might be not a regression. The possibilities are: (1) it was tested by using non-GNU operating system. (2) Tests didn't cover characters (b, B, w, W, s, and S).

For the reference sanitize_regexp was introduced in this commit from 2007 to "Protect against malloc bombs.": and I see no changes to it (except typo correction) in git blame in trustdb.c.

Well, I gues it's complex enough to warrant strategic discussion, which can be done in this ticket :)

I built gnupg 2.2.1 with the patch from D450, but that didn't help.
I even got an additional error:

In the autocrypt spec, this is called a "setup code", not a "backup code" :)

So maybe there is also a display problem, as I saw 0:00 in Kleo. I have to recheck.

Yes, it will be in 2.2.3. It's too late for 2.2.2.

The default for the timeout are 100 seconds. I will chnage that to 15 seconds which is the same what we use for keyservers.

So is 380bce13d94f the correct fix? If so, I will update the OpenBSD port including this as a local patch.

I believe this is due to the bug of gpg-agent. So, I put this report as a sub task under T3276: the calibrate_get_time() function depends on a system that has a non-tickless kernel.

This is a bug in gpg-agent.

Implemented in a branch: gniibe/scd-kdf-support

I confirmed that clock is better on FreeBSD, too. And FreeBSD has clock_gettime with CLOCK_THREAD_CPUTIME_ID.
I tested FreeBSD 11.1 running QEMU.

Could you please testing gpgme with D450: clock_gettime if CLOCK_THREAD_CPUTIME_ID is available. for GnuPG?

# My update of D450: clock_gettime if CLOCK_THREAD_CPUTIME_ID is available. has gone somewhere. So, I update it again.

Use clock instead of times.

Thanks you very much for your quick reply. I added your code to my invocations for decryption and signing and all is well now. You probably saved me many hours of searching with your kind reply!

This dialog actually belongs to Kleopatra. I added the respective tag.

However you can tell gpg-agent to let gpg ask for the passphrase. Add

Passphrase handling changed a lot with gpg 2.1.

I'll try that when it happens again. Thanks

Can you try to kill the gpg-agent process from the task manager before you create the second keypair? If that helps the problem might be the same as T3378. Are you creating a standard key (ie. rsa2048) or something else?

The OS runs Windows 2008 R2 , on a Oracle's Virtualbox, so I wouldn't consider this being a headless Windows installation, why? When you first create your keypairs it goes pretty fast usually under 5 mins. But if you recreate or try an create a new keypair it never completes, takes 20+ minutes or longer. But if you shut down the OS, or restart the OS, and try it again then it completes in under 5 mins.

We won't have a solution for 2.2.2 but I added --2k-count as a workaround
(rG78a6d0ce88ae) and the GETINFO subcommands s2k_count_cal and s2k_time.

Also failed to replicate on Windows-7 using a dedicated laptop.

I have still problems to reliable replicate this bug. I tried on Windows-7 on real hardware without success.

Done. Will go into 2.2.2.

I confirm that applying the patch fixes the hang under a VM, and does not adversely affect running on a bare metal machine either.

Please explain what you mean by "recreate the keypairs". What do you mean by "server" - are you using gpg4win on a headless Windows installation?

Could you please try D450: clock_gettime if CLOCK_THREAD_CPUTIME_ID is available. patch of GnuPG?

That's your building problem, not the problem of gnupg.

What I use to force the old keyring format is to export a public key to a file and rename that to pubring.gpg. And of course delete the pubring.kbx.

This is suuper useful! I can see there is a pSUBKEYEXPIRE, but no para_name for this. Can an expire date be passed for a subkey via Subkey-grip?

I cannot explain why it works now

Put

log-file /foo/bar/dirmngr.log
debug network,dns,ipc
verbose

into ~/.gnupg/dirmngr.conf and restart dirmngr "gpgconf --kill all". Then run your gpg command avain (a single -v is sufficient). Does the log reveal something?

Thanks. that was a good hint. I merged your report into T3378.

I tested for several days with logging enabled but was not able to replicate it again. Then I tried again w/o logging and couldn't replicate it either.