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:

@gniibe Thank you!

Applied and pushed.

The last fix was in 3681ee7dc1e9d8c94fdb046d7be0bbcfeba1cfe9, on 2017-07-05.
And it is included from the release of 2.1.22.

allow-loopback-pinentry in gpg-agent.conf is actually the default. This options advises gpg-agent to accept a request for a loopback-pinentry. If you would configure no-allow-loopback-pinentry, requests from gpg to use a loopback pinentry are rejected.

@gniibe - Thanks for your explanation. Is --pinentry-mode=loopback the same as specifying in ~/.gnupg/gpg-agent.conf:

I believe the problem was fixed in the master of pinentry with newer gpg-error-config and libassuan-config which support cross build better.

Confirmed that the support of --no-global-grab doesn't work well.

My message above is: The reported issue of ^C was fixed in pinentry-tty and GnuPG in master branch. Please test that fixes.

Please note that pinentry-tty/curses is a kind of emulation of CLI user interface, it's not the real one (I'm going to explain in the next paragraph).
It is, by any means, not robust, as users would expect, from the implementation's view. It only works specific simple use cases (while I do my best to stabilize it in master branch of GnuPG).

That is actually a GnuPG thing. We originally did it this way to help people remember their passphrase before they start using the key. I agree it is annoying and I would like to remove it too. At the same time we should really think about making no-passphrase the default and require it only with certain compliance settings.

The most plausible fix to the Y2K38 problem on 32-bit machines is to simply move to a 64-bit time_t at the same time as any other major system-wide ABI break. However, if that ABI break doesn't also change the size of long to more than 32 bits, GPGME will remain unfixed in spite of any architectural correction.

Fixed for 2.2.19 and master