I am sharing completed info, please look into it, at may I know the cause
gpg: enabled debug flags: lookup
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search 0: SUBSTR: 'JPMCBANK_GPG_PROD_2020'
gpg: DBG: keydb_search: searching keybox (resource 0 of 1)
gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => Success
gpg: DBG: finish_lookup: checking key 88BEBD28 (all)(req_usage=1)
gpg: DBG: checking subkey 022E17B7
gpg: DBG: subkey might be fine
gpg: DBG: using key 022E17B7
gpg: using subkey F423A07D022E17B7 instead of primary key 9D09927E88BEBD28
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search 0: SUBSTR: 'JPMCBANK_GPG_UAT_2019'
gpg: DBG: keydb_search: searching keybox (resource 0 of 1)
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search 0: LONG_KID: 'BFFCAF61B48701FD'
gpg: DBG: keydb_search: searching keybox (resource 0 of 1)
gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => Success
gpg: DBG: finish_lookup: checking key B48701FD (all)(req_usage=0)
gpg: DBG: using key B48701FD
gpg: using pgp trust model
gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => Success
gpg: DBG: finish_lookup: checking key B48701FD (all)(req_usage=2)
gpg: DBG: checking subkey 403048E0
gpg: DBG: usage does not match: want=2 have=1
gpg: DBG: no suitable subkeys found - trying primary
gpg: DBG: primary key usage does not match: want=2 have=5
gpg: DBG: no suitable key found - giving up
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search 0: SUBSTR: 'JPMCBANK_GPG_UAT_2019'
gpg: DBG: keydb_search: searching keybox (resource 0 of 1)
gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => EOF
gpg: JPMCBANK_GPG_UAT_2019: skipped: Unusable public key
gpg: E:\New\steps.txt: sign+encrypt failed: Unusable public key
gpg: secmem usage: 1376/32768 bytes in 3 blocks

Multiple confirmations -> Resolved.

With git bisect I tracked it down to a0326ffb755c4a49a259cea3d83831d9ede7d5d9

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.

Duplicate of T3576

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:

I can't tell you from your input what is wrong with your key. Please run

I can also confirm that 2.0.6-beta9 fixes my issue with this too. Also with my own exchange server!

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.

Thanks for having a look :)

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?

Thanks for the patch. The "fixme" indicates that I probably was just too lazy to add and test support.

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 can confirm that this appears to be fixed in 2.0.6-beta9.

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

We now have update handling in the installer and this is the first thing the update handling fixes.