Did you try to sign and encrypt with an X.509 or S/MIME key or with OpenPGP Key?

I added the workaround in the Wiki: https://wiki.gnupg.org/Gpg4win/releases/3.0/notes

Thanks Werner for your suggestion, but what I am wondering is , in the previous versions "--passphrase" option would be used to provide passphrase in the command line and thus prevent prompt to get input from us every time. This helped to automate the encryption process. But now in 3.0.0 regardless of option, it keeps prompting for passphrase.

The private key, which is protected by a passphrase, is handled by gpg-agent. If you really don't want a passphrase (you have it in a script or the command line history anyway) I suggest to remove the passphrase from that key. Other options are

See T3441 for one additional screenshot with error codes.

The log file shows that gpgex (or explorer) crashes.

The output from gpgsm -K in the last quote is perfectly okay. -K works by iterating over all public keys and checking for each public key whether the private key part is also available. If the private key is not available gpg-agent returns an error.

Indeed the notes for QT 5.9 do not anymore show Vista as supported. Stupid decision if you ask me.

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).

• 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.

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 agree that it is better to keep it in two directories.
(The potential advantages outweight the drawbacks.)

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

I see.

With the GPG4Win 3.0 Release, the software is differently distributed to the System. In the 2.x releases it was one folder (usually C:\Programms\gpg4win), now it is distributed to two different folder (C:\Programms\gpg4win and C:\Programms\gnupg). So the complete GnuPG files have been rearranged to their complete own folder.

Sorry, I don't understand this. Can you please elaborate?

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.

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.

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

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.

@aheinecke thanks for your findings.

I suspect CRL / Root certificate fetching because it works after you once manually investigated the certificate chain through -> Properties -> Digital Signatures.

We now explicitly delete the body instead of relying on the fact that the Outlook MAPI to MIME conversion deletes the body. Somehow this worked in the past but no longer does. I could not bisect it as 1.4.0 showed the same problem but old test mails from July 2016 did not show the problem. Newer ones from August 2016 already showed it in the sent mails folder.

This is fixed now with ef038f2d1db15ef14c238137c1c42a99bbe25f42 initially we only took the first attachment. Now we check for the position of the created MOSS attachment. This explains why a second try worked because the MOSS was already created.

ENABLE_NLS is not defined as it should be but we still have to define L_ in that case if simple_gettext is used to have some gettext. This was fixed by 6158811304937b592601ef30c29c5a5cdbaa88ea

Thanks for your report. Indeed this accidentally was broken in the last release. Fixed now. As a workaround copy libintl-9.dll to libintl-8.dll and rename it back in the portable directory afterwards.

A new installer is now available:

Patched installer is better. This is also a good test on whether the build works with custom patches.

Or you publish some gnupg-2.1.23-beta3 or so. Would also be ok imo.

I'd say a patched installer with a different date. This is how I would have handled this in the Gpg4win 2.x times.

How, shall we build just a new patched installer or do a full new release?

That was an easy one.

I can't reproduce this I even tried to completly remove TCP/IP from the DCOM Protocols. No problems.

Workaround is to add

Sorry. Git log had some ...skipping which i overlooked instead of 3419a339d9c4e800bf30e9021e05982d8c1021c1 the actual one is 9b43220b8ad1a5c1cd51de3bbfff7ccbcc3fa877

It's either rev: 5b9025cfa1f9b1c67ddf2f6bf87d863e780cf157 which does not compile by itself or 3419a339d9c4e800bf30e9021e05982d8c1021c1

Uhm. I can't reproduce this with a dirmngr built on my development system.

All fixed. (famous last words)

To remain compatible with PGP6 we are limited to ustar. If you want to support other archive types, archive first and then encrypt/sign the archive.

Fixed with https://commits.kde.org/kleopatra/3e08e4d25d34140a1d03e02c7bd9d066120d0baa

Ah no. GpgME is not at fault. Kleopatra just eats the status and only shows system error. Have to fix this in kleopatra.

To make it easier to reproduce

87703dbb86ac8fd8abd23170f8038ea6e3dbde28 was the offender. It called _gpgme_split_fields on a non fatal decrypt error which resulted in a mangled error passed to verify.