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

I agree with everything in the previous comment. Just hoping for simple, robust UI like gpg 1.x that works over an SSH connection (no GUI) for ordinary file decryption on the command line.

@dkg I use gnupg 1.x for a very, very long time. I like the way it works. And most, I like that the terminal is not hidden from me when I type a password and that the characters in password does not appear on terminal as "*". Sometime the text in terminal is important to me. pinentry-tty have more or less the same behavior as gnupg 1.x. With pinentry-curses the terminal is hidden and there are '*' for each character in password that I type. Also, there is not GUI on my servers so no pinentry-(qt|gtk|anything else).

Very few OpenPGP data signatures have an expiration time either, fwiw. I have never actually seen one in the wild, and no one that i know uses --ask-sig-expire or --default-sig-expire (it shows up in the cupt test suite and the apt test suite, but doesn't appear to be actually used by anything).

CMS signatures do not have a expiration time. Further the meaning of the expiration time of one of the certificates also depends on the validation model (shell or chain); thus a one-to-one relationship between these times is not possible.

We will run into all kind of problems after 2038 on 32 bit boxes. 2106 is nothing to care about.

pinentry-tty is pretty fragile, and designed to be handled in a particular way. I strongly recommend a different workflow if you're using gpg secret key operations in a regular process. either:

@maiden_taiwan Thank you. Nice trick. Works fine for for one file and covers almost all of my issues.
Still, for example, when used together with rpmsign and I have to sign multiple rpms files, is inconvenient to type ctrl-D for each rpm file (for whatever reason I want to stop the signing process) . ctrl-c just stop the process.
This worked fine with gpg 1.x. Not so much with gpg2.

Thank you.

I uploaded the certificate files. For a test please do the following:

@gv: I am another user (not the developer), but here is a workaround I found. Type ctrl-D instead of ctrl-C to terminate pinentry-tty.

I'm sorry, this issue is far from fixed.

Regression due to a faulty backport. Fixed in repo; patch is F1052802
Thanks for reporting.

Okay, I can replicate that on gnupg 2.2; it works correct on master.