FWIW, I found an open xterm with my query from last week:

For GNU/Linux or GNU/kFreeBSD system, libgcrypt 1.8 with libgpg-error 1.36 has no problem in Debian build:
https://buildd.debian.org/status/package.php?p=libgcrypt20

In solaris11openindiana-log2, we have two errors: one for ulong, and another for ushort.
I fixed the former. It is because of our mistake of using ulong before it is handled by libgcrypt/src/types.h. In the first place, it is implemented by "unsigned long", so, there is no need to use ulong here.

@Valodim: I am pretty sure that last week it resolved only to a v4 address; today (and from another network and resolver) I get the same addresses as you.

that does look like your host can resolve domains for ipv6 addresses, but can't actually connect to them. what does host keys.openpgp.org say? And ip a?

Thanks. I see the situation for Solaris 11 Openindiana. In master (will be 1.9.0), it has no problem.
We need to fix in 1.8. I will.

Here are the logs. The package was configured with
CC="gcc -m64 -O2 -D_XOPEN_SOURCE=700"

Please give us log for Solaris 11 Openindiana.

I think that this ticket and https://bugs.debian.org/346241 handle different things, although both do key selection.

but keys.openpgp.org resolves only to a v4 address.

This is also https://bugs.debian.org/346241

ping keys.openpgp.org

As far as I know this is a v4 only network. I tried what you said and get this log:

2020-01-17 15:39:33 dirmngr[18656.6] DBG: chan_6 <- END
2020-01-17 15:39:33 dirmngr[18656.6] DBG: dns: libdns initialized
2020-01-17 15:39:33 dirmngr[18656.6] DBG: dns: getsrv(_pgpkey-https._tcp.keys.openpgp.org) -> 0 records
2020-01-17 15:39:33 dirmngr[18656.6] DBG: dns: resolve_dns_name(keys.openpgp.org): Success
2020-01-17 15:39:33 dirmngr[18656.6] resolve_dns_addr for 'keys.openpgp.org': 'keys.openpgp.org' [already known]
2020-01-17 15:39:33 dirmngr[18656.6] resolve_dns_addr for 'keys.openpgp.org': 'keys.openpgp.org' [already known]
2020-01-17 15:39:33 dirmngr[18656.6] number of system provided CAs: 142
2020-01-17 15:39:33 dirmngr[18656.6] DBG: dns: resolve_dns_name(keys.openpgp.org): Success
2020-01-17 15:39:33 dirmngr[18656.6] error creating socket: Address family not supported by protocol
2020-01-17 15:39:33 dirmngr[18656.6] error connecting to 'https://keys.openpgp.org:443': Address family not supported by protocol
2020-01-17 15:39:33 dirmngr[18656.6] marking host 'keys.openpgp.org' as dead
2020-01-17 15:39:33 dirmngr[18656.6] host 'keys.openpgp.org' marked as dead
2020-01-17 15:39:33 dirmngr[18656.6] command 'KS_PUT' failed: No keyserver available
2020-01-17 15:39:33 dirmngr[18656.6] DBG: chan_6 -> ERR 167772346 No keyserver available <Dirmngr>
2020-01-17 15:39:33 dirmngr[18656.6] DBG: chan_6 <- BYE
2020-01-17 15:39:33 dirmngr[18656.6] DBG: chan_6 -> OK closing connection
2020-01-17 15:39:33 dirmngr[18656.6] handler for fd 6 terminated

The problem is likely that you don't have IPv4 support but keys.openpgp.org resolves only to a v4 address.
You should also use

An updated build is available here: https://files.gpg4win.org/Beta/gpgol/2.4.6-beta3/

thanks for the fix, @aheinecke ! can you post screenshots of the changes? or do you have a nightly build i could test?

I have checked the eMail header of the eMail from Sender X in the Exchange mailbox of User A and I see Sender X is using Mozilla Thunderbird and I tested it with Thunderbird also, but it works for me.
I cannot provide all details of the eMail from Sender X because it's a customer of another customer, but I have replaced the IP addresses and other private information in the eMail header and this is the result:

thanks for the report. This is definitely a sore spot and we need to look at it again. I did some experiments a while a go trying to fix this issue but so far I was unable to get to stable results so for now this is a known issue.
I'm a bit suprised that the workaround with not having the mail open does not work for you.

This again,...
That error always occurs when the Exchange Server is unhappy with the structure of our PGP/MIME Mails. It has nothing to do with S/MIME, that is only because Exchange only knows about S/MIME, so our PGP/MIME Mails also claim to be S/MIME mails.

Display now looks good to me in all cases. We still keep the subject when a reply / forward is done, but that is the same as before. To do this properly I would have to actually do the protected headers sending,.. as then I could automatically flag such a message to be sent with protected headers. But that would be a new feature and I rather work on properly doing BCC sending as the next privacy enhancing feature.

Reported.

You may.. Comments were relevant. Bye.

FWIW, the GTK and QT pinentries do have a qualitybar. However is is only enabled:

At least one configuration error I could identify by myself: Kleopartra -> GnuPG-System -> Smartcard -> Connecting Reader with port N. If it is written: Yubico YubiKey OTP+FIDO+CCID 0 then Yubikey is recognized. I forgot to write "Yubico Yubikey" at the beginning and the "0" at the end. Now smart cards and Yubikeys are working for gpg. What is still a problem is SSH. A SSH key is on smart card or the Yubikey.

In T4809#131931, @werner wrote:

BTW, the qualitybar is not shown by default, only if you configure sme of the extra password checks. We may even remove it completely because it leads to wrong assumption on why a passphrase is required.

@Rycky_Tigg cases 1, 2, and 3 that you document here each show the behavior that i would expect from pinentry-gnome3, given the definition of its Assuan-based API and its use of gcr-prompter. (i'm assuming that in case 3 the user just waited longer than the allowed timeout)

Thank you for resolving this issue! I am successfully using version 2.2.19 from the gnupg (2.2.19-1~bpo10+1) package of Debian Backports.

"more specific about what you think is wrong"; From https://bugs.kde.org/show_bug.cgi?id=412569 copied)/pasted:

BTW, the qualitybar is not shown by default, only if you configure sme of the extra password checks. We may even remove it completely because it leads to wrong assumption on why a passphrase is required.

pinentry-gnome uses gcr's gcr_prompt_set_password_new to prompt for a new password, and ignores the SETQUALITYBAR assuan command.

It seems that gnome-keyring-daemon has some incompatible changes which breaks that version of pinentry-gnome. Or GKR has not been setup properly. I'd suggest to use pinentry-gtk until folks with knowledge about Gnome folks have figured out what is going wrong.

Hey. As reference – Complete set of features while run in Windows.

Please describe which features are missing.

Werner, no silly questions exist, only silly answers are existing. However, Yubikey is enabled for usb. I using Yubikey Manager a GUI, for the USB interface it is enabled: OTP, FIDO, FIDO U2F, OpenPGP, PIV and OATH. Thanks also for the suggested command line test. Indeed an error code shows up:

Maybe a silly question, but let's be sure: Is the Openpgp app enabled on that Yubikey and is it enabled for usb? I can't remember the Yubikey commands on how to check this but tehre should even be a GUI. These days I use the new gpg-card tool to manage my Yubikeys (from GnuPG master).

Please, note the following uncommon behavior:

I'll keep this on needs triage because I don't know what the issue could be. I have a yubikey 5 at hand and just tested it with Gpg4win 3.1.11. It works without problems.

note that it *does* sometimes hide the legacy display part, for some messages, including unfortunately-complex -- that's good! -- but maybe this points to some internal inconsistency:

Sorting the table is a good idea for reproducibility, since otherwise the tree depends on the order of the arguments to asn1-gentables, which are generated with a wildcard expansion that might be shell or file system dependent.

Frankly, I am not sure why we sort that table at all. Your patch does not harm, though.

Here's an excerpt of the output which should cover the critical step. Let me know if you need more/all.

Sorry, there have been quite some bindings with similar names, so I couldn't identify which one this is about. Can you please run with your test code with GPGME_DEBUG=9:/foo/gpgme.log set which makes it it easier to understand what is going on.

Hi, this is using the Python language bindings provided by GPGME. I am the author of gnupg.py which my attempt to use those bindings to revoke a signature.

I do not know this Python library. It looks like one of the older binding to GPGME. Please contact the author of gnupg.py or switch over to the Python language binding we provide with gpgme.

PS I forgot to say why movement to cmake will be the best way.

I totally disagree.

Please read libgpg-error's README. For each architecture we need to have a dedicated config file - this has nothing to do with autotools. Big and little endian variants are obviously different architectures. Here is an excerpt from the README

Hello @wener, I want to say that libgpg-error is the only one (!) application that fails to cross compile using valid toolchains: "armeb-unknown-linux-gnueabi" and "aarch64_be-unknown-linux-gnu". It compiles and runs perfectly using "arm-unknown-linux-gnueabi" and "aarch64-unknown-linux-gnu", but fails with big endian. I see project are actually using "hton/ntoh" so we shouldn't see this error. What this problem is about?

Fixed in master and 2.2

there is no way to handle this correctly with such messages. The PGP Standard says that PGP Messages may have every encoding. This is a reason why we always talk about "you should use PGP/MIME" as this is basically PGP with added handling for content meta information like the text encoding.

Related task: About subkeys is T4028

Prio raised and assigned to werner as he asked for it.

Thanks for examination.
Providing an 'untouched .msg' seems to be complicate because OL receives several encrypted mails all day long, so GpgOl must be activated for common use. Additional: To avoid this issue, .txt mode has been deactivated, .html is allowed without downloading foreign items or pictures.

Thank you for the good report.

Thanks for the report.

Thanks for the report but I cannot reproduce the issue :-/. In multipart alternative mails GpgOL takes the text part if text mode is set in Outlook.

Will be greatly improved with 3.1.11

fwiw, ensuring that overflow for either field results in ULONG_MAX (rather than wrapping around) would go a long way toward this problem being something that we can reasonably put off for another 50 years.

I found a solution for master and 2.1.19 which minimizes the risk of regressions:

In case you use gpgme we have a flag which can be queried to see whether a redraw is required: