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.

Yes, I put the tag of gpg2.2, as it's useful to compose key from external source.

By the way: This is when I try to use a key stored on my hard disk. I have never had any issue like this with those keys in previous versions, but I have always had similar problems with keys stored on my smartcard.

Shall we mark that for backport to some 2.2 version?

gpg is required by several parts of GnuPG. Tracking dependencies for it for the esoteric case of not building it does not make any sense. Thus the option will be removed from from master.

Changes for Gnuk is done. It's now testing. It will be in Gnuk 1.2.7.

Did you run gpg before your copying $HOME data and after your installation of Stretch?
That gpg invocation create the file ~/.gnupg/.gpg-v21-migrated, which marks "the migration finished".

What do you think about a special case for the homedir "/dev/null" ? We use this device as a specila value at other places too. I have often seen "/nonexistent" in /etc/passwd but there is no standard for this. However, /dev/null is well defined.

Actually before the fingerprint, which is a general argument and not an argument to -k. Thus

OK, closed.

GnuPG is picky about the order of options. Please put "--list-options show-photos" before -k.

How about adding support with private in keyparam?

• (genkey(rsa(nbit 2048)(d xxxx)(p xxxx)(q xxxx)(u xxxx))) ; Only p and q, is OK
• (genkey(ecc(curve cv25519)(flags djb-tweak comp)(d xxx)))

I am experiencing this error too and did not see any way to get to the Pinentry window. Only after killing the hung outlook process did the Pinentry window pop up.