I've got libgcrypt-1.8.1

Just to inform that it is not a single problem.
I recognized exactly the same behaviour.
After terminating the gpg-agent task everything works as aspected (up to the next non-activity phase).
64-bit Windows 7 Enterprise, Outlook 2010, GPG4Win Version 3.0.0-gpg4win-3.0.0.

Raising priority so that we have a chance to review this for the next 2.2 release.

Closing due to compiler error.

I can confirm this behaviour in the production version:
Outlook Professional Plus 2013 (15.0.4953.1001) in a corporate network (32 bit)
Create new message, no automatic selection of PGP key, S/MIME support both enabled/disabled, sometimes it works (after a fresh start of outlook), but after some idle time creating and signing new messages is no longer possible, the key selection dialog opens, but then nothing.

Now, 2.1.22 or later supports automatic selection of secret key by available key on card.
Closing.

[Shameless self-kudos]

That was fast ;-) But a bit of luck too since I sually don't show up at the tty late in the evening.

But not for 2.2

This is more or less what gpgme does/sees when loopback mode is enabled / disabled:

OK, I changed my own purpose. I don't touch internal representations.

ntbtls 0.1.2 has been released as well gnupg 2.2.1 with other fixes and the Windows installer using that new ntbtls.

IIRC, the actual reason for introducing GPG_TTY was a problem with GTK which required a tty for whatever reasons. The original user for the curses pinentry was Mutt and that didn't require that envvar. A much, much better solution would be a fixed ctermid(3) to return the real controlling tty and not the virtual tty /dev/tty. Unfortunately other libc implementations behave the same (I just checked OpenBSD).

I added the missing curves to ntbtls and will soon do a new release. To please some folks here I also added the Brainpool curves ;-)

You can't access that server even from Windows7 due to an uncommon ECC curve. I need to investigate but it is likely that ntbtls does not yet support it.

Looks resolved in beta 307. Signing and exporting to public is now so fast even the first time around that I can't reproduce this condition.

Resolved for me with beta 307. Kleopatra gets launched, starts a few GPG services, then the message gets signed. It takes 20-30 seconds, but that's expected. It's much faster after the first time.

False alarm, this should be closed. It was caused by enabling SMIME support in GPGOL while the sender only had an OpenPGP cert, no SMIME cert. Hence Kleopatra threw a message that it could not unambiguously determine the right cert, then offers only one cert (OpenPGP) for user.

Tested Beta 305 which was more or less fine, today installed Beta 307 and have problems again. The problems today are so far only Oulook hangs, which resolve after around 15-30 seconds. Sadly once it started with the first hangs, it hangs a minute (or so) later again and I can barely change the mail. Those are all plain mails, without any encryption/signature.

Please write a proper bug report. Pasting some compiler output into the TITLE field is not a proper bug report we will look at.

Committed to both branches (master and 2.2), so, closing.

make shure you only use 2 registers !!! 32bit: eax, cl and 64bit rax, cl

If you create a file without -a the standard suffix will be .asc. But if you use -o FILE, just must give the full filename..

Just for information:
The gnupg version does allow .asc output.
As a workaround I created a batch file consisting of the lines

The new unified compliance checker was not initialized. Fixed in the 2.2 branch.

Fixed in master.

I'm fine with (and i totally understand) wanting nothing but UTC in the machine interface and internal representations.

I'm having the exact same issue, also Outlook 2016 and Beta 299.
[edit]
I want to add, my Outlook also often freezes by just changing the folder. Outlook will try to open a message when chaning the folder, but regardless if it's encrypted or not, Outlook might freeze.
I did not change any GpgOL default settings.

[copied from gnupg-devel@]

I can replicate this even with master. Good catch.

success, thank you for the help!

In GnuPG 2.1, secret keys are under control of gpg-agent. Currently, it is not deleted by gpg frontend.
Please run:

$ gpg -K --with-keygrip

The only mitigation I can see for this is a better error message.

I think any existing script that assumes UTC should add an explicit Z suffix. (that is, i don't think the breakage is a big deal, and anyone writing scripts that needs this kind of precision will be more likely be thankful that we have a sensible, normalized interface).

It is pretty much confusing. When a user specify in YYYY-MM-DD format with no hh:mm:ss, it is interpreted as local time (noon of that day).
When a user adding Thh:mm:ss, it is UTC.

While I confirmed that GnuPG interprets YYYY-MM-DDThh:mm:ss in UTC (which should be interpret as local time according to ISO-8601), I don't know how we can fix this.
If I change the interpretation of GnuPG (possibly supporting the format with Z suffix and timezone), it may break existing script which assumes UTC.

Bug confirmed in rGa766a37290cf: Print keyid in gpg --list-packets..

When Thhmmzz is specified, no adding 12 hours, that's the intention of the code, I suppose.
However, the implementation is wrong, since the beginning (not supporting "Z" or timezone for ISO-8601. interpret the string as UTC).
I will take that, too.

Is it possible that this is related to T3278 ?

I think that adding 12 hours by parse_expire_string make sense.
The test suite should be fixed.
I will.

fwiw, i agree that GnuPG should interpret these as ISO-8601 strings. At the very least:

Nice find, @gniibe ! So this looks like a bug either in GnuPG's test suite, or in parse_expire_string, right? How do you think it should be addressed?

In the log, I found:

Possibly, timezone (of build machine) matters.

Please try this patch: