The install location does not have anything to do with that. I just always have my development installations directly under C: so that I can modify them without admin rights.

@hs could you please retest with 2.0.6-beta8 http://files.gpg4win.org/Beta/gpgol/ and attach the log file again.

As this is still waiting for info for two years and I can't reproduce with current GpgOL -> Resolved.

Implemented with: https://commits.kde.org/kleopatra/9d1ebcb1e5f6b44a745c7e947f2e8eaf88fff786

This is strange, something in your setup must be different from other users. Any Idea what might be special for you? In your log it looks like only the send event for the encrypted mail is passed.
Where do you send your mails to, to another user on the same exchange server?

I believe that this was fixed in T3658 which reported more clearly what was attempted to verify and what failed.

Indeed, thanks for the note. I added the variable only later on for the check of protocol unknown and overlooked to update the setProtocol call.
I've updated the code accordingly.

I can reproduce the issue but only for PGP/Inline, encrypted only mails. PGP/MIME works finde. This allows for an easy workaround (sending PGP MIME) so Prio down to Normal.

Fixed with https://commits.kde.org/kleopatra/066c6e4ca82d064437f1902838d09fa903147e40

While trying to reproduce another bug I've set up an account with Exchange Online. With that account I had similar behavior with empty mails shown. The behavior also matched to the logging of the last mail in your log.

You might want to look at: https://wiki.gnupg.org/TroubleShooting#Passphrase_on_the_command_line

Can you please run debugview ( https://technet.microsoft.com/en-us/sysinternals/debugview.aspx ) and attach or paste any lines here that start with "org.kde.pim" when you try to encrypt the folder?

Thank you for your report. I can reproduce this problem. Kleopatra correctly looks for the signature file but then fails to set the protocol. This results in an internal error.

Prio High as this makes GpgOL unusable in such a setup.

I give this high priority as sending unencrypted is pretty much a worst case scenario. :-o

In T3714#109045, @Lloyd wrote:

I appreciate the dangers. Whilst I try and persuade the sender to deal with the issue at their end, is there anyway to include this option in GpgOL on a temporary basis?

As answered in the forum: https://wald.intevation.org/forum/forum.php?thread_id=1837&forum_id=21&group_id=11 :

Unsupported Protocol means that GpgOL can't find your GnuPG installation. Maybe something went wrong during the install of Gpg4win?

Kleopatra's debug output can be seen with DebugView https://docs.microsoft.com/en-us/sysinternals/downloads/debugview

I can't reproduce this with Kleopatra 3.0.1 from Gpg4win 3.0.2. It just works as expected. Both if I encrypt the files as an archive or if I encrypt them seperately.

You start Windows Explorer (the file manager thingy)

I could somewhat reproduce this problem when I disconnected the connection to Exchange from my Outlook and then tried to respond to an exchange mail. Although for me Outlook did not Hang and an error message (with a General Error) showed up.

Thanks for the report and the log.
I see the problem. In your case of a reply outlook does not give us the SMTP address for the recipient but an Exchange DN

Fixed with: https://commits.kde.org/kleopatra/c85bc8ebbe8594be9309e3e8a0945a5dbb90828c

Also the Name and E-Mail split in the table looks ugly. While technically they are on different UserID objects it would be prettyer to combine them.

@hs Your log is interesting but I don't yet understand it. We see a "Load" event for an encrypted mail, create our internal data modelling. But later there is a mismatch between the reference Outlook gives us and our internal reference (Failed to find mail in map).
Out of the blue there might be something I could do in that case but it's still somewhat unclear to me why this state occurs.

Debian has this with migrate-pubring-from-classic-gpg ( https://sources.debian.org/src/gnupg2/2.2.3-1/debian/migrate-pubring-from-classic-gpg/ )

Please reopen or comment if that problem still happens if you move away the gnupg home directory.

This goes to wontfix I investigated and there is no way to attach a file trough the mailto protocol with outlook. Only the parameters from https://msdn.microsoft.com/en-us/library/aa767737.aspx are supported.
Theoretically Kleopatra "could" use MAPI to achieve creating a mail with attachment but this would be overkill. Kleopatra puts up a big warning that attaching may not have worked and ok.

Case Insensitive Sorting is fixed with:
https://commits.kde.org/kleopatra/856aad228a81f542f821209ae2c796d9b7160263

Well the problem is both TCP and UDP. Somehow dirmngr tries to open a listening socket. I think that may be some feature probing in the DNS resolver. Because if the Firewall access is denied I don't see any feature loss.

The HTML in the body below the text on the GpgOL-1.4 side is a known issue of GpgOL-1.x we only added proper HTML handling with GpgOL 2.
GpgOL before 2.0 just appended the text/html mime part to the text/plain mimepart in multipart/alternative mails.

Strange, do you have any unusual Group Policies or some "Security Software" that might interfere with the running of GPA / Kleopatra (they open a local socket).

In my tests it's fixed with: b8276a4f3acecee2e467c0530007aedc9db5936a the plain text body now uses similar code to the html part. Makes sense anyway. The difference was mostly historic as GpgOL before 2.0 did not handle HTML parts at all.

If I send "Nur Text" (plaintext only) under formatting it works as expected. We query Outlook for the Body from the MAPI Data model and just get the wrong value returned. For the HTML part we use the Outlook Object Model (as we had a similar problem there that the MAPI data was not updated properly.)
The fix is obvious. We can use similar code to our handling of the HTML body. This is a workaround for an Outlook bug IMO, why should sending from drafts differ from the usual sending *sigh*

I can reproduce that problem and have opened T3614 for this.

This is the question:

Forgot to mention the revision. It's https://commits.kde.org/kleopatra/0428c744fbd56a305d3e249215d74fe6ad811acf

I implemented a text export action that uses the details of a certificate as comments. This will bring back the old copy & paste able details and has the additional advantage of a nice and quick export.

T2854 is a duplicate of this but contains more up to date information. So I'm closing this issue.

Does this still happen with gpg4win-3.0.2?

Gpg4win 3.0.2 is released which contains even more fixes for GpgOL -> Resolving this. Please let us know if you still have Problems that are not tracked here.

This works now. There is a problem still if the agent is not running with the default homedir or under other users. But this is handled in T2146

This works now. There is a problem still if the agent is not running with the default homedir or under other users. But this is handled in T2146

@werner This is sometimes still an issue. E.g. if the agent is started with a different homedir. Is it ok to just use TerminateProcess on any gpg-agent?

I'm changing this issue to resolved as I opened T3601 and T3602 for the problems mentioned in this issue. As it is better to have them separated.

I thought about (2) when implementing the new "decrypt" action in Kleopatra but we did not give it high priority as we were unsure if this is a real world problem.

sadly this happens with nearly every release that some Anti Virus software reports false positives ( https://wiki.gnupg.org/Gpg4win/AntiVirusSoftware )

*cough* That change made it into Gpg4win 3.0.2 *cough*

There is now also Gpg4win-3.0.2 with that gnupg version available.