It is reproducible on my Debian (stretch). I'm going to minimize the case.

No more reports of this since 3.0.2. With 3.0.3 I fixed an additional memleak which should further improve this. Resolved for now.

For the 3.0.3 I tested more with Microsoft Exchange Online, an Exchange 2012 Server and could not reproduce such problems. So I'm lowering the priority to normal as I don't think many users are affected.

I have exactly the same problem on my Windows 10 machine. I am using bitdefender as virus scanner, but it doesn't work no matter if it is active or not. Windows is fully updated and I am using gpg4win 3.0.3.

Have posted in gcrypt-devel mailer.. thanks

The actual problem is that justus quit his job to work for pEp. Thus we have no maintainer for the python port. There is one candidate for this job but don't expect any fast fixes because one of the near term goals will be to replace swig so that we can provide the bindings also for WIndows. Maybe that will also solve the problem with different Python versions.

it's too bad that this is not considered something worth fixing upstream -- at the moment, debian's python3-gpg will only work with one specific version of python3 because of this, which makes package transitions more complex than they should be.

Will be posting it in gcrypt-devel shortly.

Hope you've got the problem with the current naming conventions for arguments and the result by going them. We should either document the arguments properly or change the code as i have pointed out. Since the iterations argument used properly in the case PBKDF2 (type8) within the same wrapper api gcry_kdf_derive.

I would also suggest to discuss this at the gcrypt-devel list so that you can get get comments from others as well.

Your are looking at the libgcrypt code. Unfortunately that does not help us. What I would like to see are two protocol implementations, using sccryptone with libgcrypt and one with anoter scruypt implementation. Do they both work? If so, there is no bug in libgcrypt's code - at best the parameter have been given different names and we can point other name use in the docs.

Here's what i got from 1.8.1 code (downloaded from gnupg).

tests/t-kdf uses test vectors from an I-D and obviously works fine. Maybe that I-D has a different parameter naming than what is used in your examples. I simply can't say without researching the whole thing. Please let t me know a concrete bug where that KDF is not compatible with other implementations. As an example here is one of our test vectors:

With the current implementation when the r is set to GCRY_KDF_SCRYPT, on a 3 core system, it almost took 35 minutes to generate the hash, where as with r=41 it was around 4 minutes and 20 seconds.
when i corrected the the values, i.e. N=16384, p=1 and r=GCRY_KDF_SCRYPT, it took less than a second to generate the hash.

Multiple confirmations -> Resolved.

Oh dear what an evening and morning. I reversed the facts I reported. Sure 2.1 is borken - that is the whole point. ( I realized that only after install 2.2.4 and generating fresh keys). To avoid confusion I will delete my last comments.

Hi @aheinecke
Its also german:

GpgOL should use the same language detection code that GnuPG also uses. If you open a command line (cmd) and run "gpg" in that command line is it also in german?

@werner It's just simple; With --personal-cipher-preferences 3DES (3DES only), make a encrypted message. Then, try to decrypt the message with OpenPGPcard (version 2.1 and later).

I've noticed that myself and the cause for this is the code which we use to ensure that the key resolution dialog of Kleopatra opens in the foreground.

Thanks again for the test, your patience and the report :-)

:-)
I can confirm, that 2.0.6-beta14 is working and until now, Outlook did not crash :-)
Great work, thanks!

Ok so I found out that you could even trigger this bug without persistent options just by activating and deactivating any S/MIME option on a mail. This somehow changed the behavior of Outlook.

The segfault from an openSUSE machine looks the same:

In T3656#109404, @aheinecke wrote:

But that's it.
With these Options set and explicitly unchecking Sign & Encrypt before sending I get the exact same behavior that you two describe. Mails are sent unencrypted.

Okay, so on Suse we have the same problem w/o the somewhat intrusive changes of Fedora. The inetresting thing is that segv code part is the same as used in Linux.

But that's it.
With these Options set and explicitly unchecking Sign & Encrypt before sending I get the exact same behavior that you two describe. Mails are sent unencrypted.

In T3656#109402, @JHohmann wrote:

Yes, I also have this option enabled:

And no, I disable Signing and Encryption, before enabling PGP Encryption for the specific email

Yes, I also have this option enabled:

I have now also the error T3662
Will try also 2.0.6-beta9

In T3656#109394, @Mak wrote:

Ahh, and yes I use a public personal s/mime cert to sign my mails. nothing else.

OK, found the problem now. Its the smime settings. I have set them to sign all outgoing mails. And thats where the problem starts...

Ahh, and yes I use a public personal s/mime cert to sign my mails. nothing else.

My too, no outgoing rules.

The issue also occurs on openSUSE Tumbleweed:

libgpg-error is version 1.27: https://src.fedoraproject.org/rpms/libgpg-error/tree/f27
You can find the patches applied to libgcrypto here: https://src.fedoraproject.org/rpms/libgcrypt/tree/f27

I do not have any rules configured that are applying to outgoing mails. (As far as I can see them with a non-administrative account)
Are there any group-policies, that might affect the behavior of Outlook regarding to GpgOL?

Another question: Any outgoing Filters (Email Rules)?

Thanks for the report. I have a few questions, though
Which version of libgpg-error are you using?
What are the changes Fedora made to libgcrypt (and libgpg-error)?
Which CPU, what compile options and which compiler version?
Can you repeat this with a stock libgcrypt and libgpg-error?

@JHohmann Your log is similar in that I can see two Write events after the send of which there should only be one. Somehow we seem to do crypto on a copy mail object and another mail is acutally sent.

I don't think that it is possible to create you an account.

Quoted Text

Any chance that I could get a temporary test account on your Server?

We have the same problem.
Sent emails are not encrypted with gpg4win 3.0.2
Outlook 2016
Exchange 2010
Locale: German
Plugins: Skype, OneNote, Sophos

This diff should include all the changes necessary to add support:
https://gist.github.com/lukele/0973e64deb9d422a648e6fbbd55573ac

I absolutely agree this support doesn't particularly make sense. A user of GPG Suite reported the issue, since their internal keyserver requires basic auth. They couldn't exactly explain why, and I told them that it doesn't make much sense.

Why do you need this for a keyserver? Keys are public and in-house keyservers should be at a local address and there need to be strict provisions not to upload to a public keyserver. Maybe LDAP or the kDNS thing (which is currently disabled) would be better for such use cases.

I find your question confusing. I'm the reporter of this bug. All the efforts and tries of gniibe and myself are documented above.
Or do you refrer to something else ?

Can you exactly explain how you tested this?

I also have the 2.1 Card which has this bug
Version ..........: 2.1
Manufacturer .....: ZeitControl

I'm using gnupg 2.2.4 and this problem repros for me, and it impacts downstream things like pacman-key (Arch Linux) quite insidiously, which fails with an misleading error message that would not point a regular user to this line of investigation.

For T3662 (PGP/Inline problem with Microsoft Exchange Online) I had to change the code used to send PGP/Inline.

In T3656#109246, @Mak wrote:

I sent it to a user on a different Mailserver. On my setup its nothing special... Win 10 Enterprise N en, Office 365 Pro Plus en, Kaspersky Internet Security. Server Win 2012 R2 with Exchange Server 2013 and GFI Mailessentials.
I don't think there is anything special... :-(

I sent it to a user on a different Mailserver. On my setup its nothing special... Win 10 Enterprise N en, Office 365 Pro Plus en, Kaspersky Internet Security. Server Win 2012 R2 with Exchange Server 2013 and GFI Mailessentials.
I don't think there is anything special... :-(

@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?

FWIW, I ran the same test with three card versions:

I forwarded the bug report to the OpenPGP card author.
I think that 2.0 card is OK, 2.1, 2.2, and 3.3 card have this bug.

I disabled all my add-ins and tested it again. Still the same. Mails are sent unencrypted.
Tried also to send a plain text message

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.

All e-mails I tried to open with 2.0.6-beta7 gpgol.dll were readable and showed the correct content in my environment, now. Great!

@aheinecke thanks for the fix. But I have a suggestion for the code(I only looked at the diff):

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.

Fixed for 2.2.5. Thanks for the report.

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.

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

Hi, Werner.
My OS has everything compiled from sources obtained from devs as they release them. Funtoo Linux is a derivative of Gentoo Linux.
Hence, the default behavior of the software is not altered except when removed some of its features, but I've installed gnupg without alteration.

So the assumption is it is an Error of the GnuPG card.
I tried today with an Yubikey 4 and it works. This confirms the theorie.
However - my preference is on the Smartcards. So how would we proceed now. Who can check for the error and correct it / flash a new version on a card.
I would offer to verify if it is fixed.

This looks more like an Enigmail bug. In particular the manual start of gpg-agent as described in the workaround is useless because gpg-agent is always started as needed. I don't know your OS and thus I do not know whether gpg-agent is used in --supervised mode, as in Debian, or in the default way. What does

The first thing you should do is to write a proper bug reporting, including your OS, any special configiration you use (e.g. using a dedicated DNS sever) and the exact commands you give and outputs you see. Always use option -v with gpg. dirmngr can create a log file: