From reading T3425, I would say that QT isn't supported anyome on both, XP and Vista. XP has the additional issue, that CancelIoEx is missing (which seems to be called from QT since Q5Core.dll uses CancelIOE).

I recieved the Log File of a user which may helps analyzing this problem further

That is a server error - the redirect is under the server's control and if the server advises to connect via http we should do that. Well, unless our policy is to not allow such a redirect - such a policy makes a lot of sense of course.

• On XP we see an error message from Windows that CancelIoEx is not availabale in XP.
• On Vista we see a different error which comes from Qt and not Windows. See above.

I don't know yet what exactly is going wrong, but it seems that it is consistently not working with standard configuration on Vista and XP.

[it seems you are using a Debian version. Thus please report bugs to Debian - they have lots of patches over standard gpg.]

Something related seems to still be happening in 2.2.1. make test passes, but here on macOS 10.12.6., my ~/Library/Logs/DiagnosticReports is full of crash reports for scdaemon. As far as I can tell from the timestamps, it looks like scdaemon is *still* getting called by the gpg test suite, even though I built gpg with the flag --disable-scdaemon.

The Vista problem seems to be unrelated to the missing CancelIoEx in XP. The error message is that it "... could not find or load the Qt platform plugin "Windows" in "".

I'm not sure this is what you are looking for, but in Kleopatra latest version (3.0.0-gpg4win-3.0.0), it is possible to use ascii armor by default in all encryptions:
Make sure you check the following options in settings:
Settings > Configure Kleopatra > Crypto operations > Create signed or encrypted files as text files

So how would one distinguish between private and public key using any kind of automatic processing?

No. GPGME can't check return codes because it uses a double fork approach.

--clearsign is for text only and canonizes the the signed text to make it robust against different line-endings and white space changes. Thus this is no bug. To get a bit identical copy you may not use --clearsign or --text-mode but use standard signing,

What you see is the public key which is always part of the private key.

GnuPG is definitely not affected. I do my release test on Vista Ultimate Pro (or whatever it was called)

Someone described this issue with Windows Vista as well.

Did just that in master and 2.2.

CancelIoEx is supported by Vista.

I think it was a version problem.
I have now installed gpgOL (2.0.1) and gpg4win version 3
It's working.
Just that emails do not directly access "decrypt", but those that are sent from MAC arrive as an attachment, with ASC termination. I need to change the extension to PGP, decrypt, and generate a file without extension. Then I need to change the extension to EML and then I'll be fine.
Can you fix it?

I assume you installed gpg4win. Which version did you install? 3.0 is the latest.

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.