Using base64 encoding for a fixed format part in us-ascii is not a good idea because in practise many PGP/MIME decoders won't be able to detect and then decyrypt such a message.

$AUTHKEYID use cases have been removed.

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:

It is a feature not a bug. For symmetric encryption the gpg-agent remembers the passphrase used for the encryption and thus for some time or until /gpgconf --reload gpg-agent/ it tries that passphrase for decryption.

I am wondering if there is any workaround or work in progress about this old ticket.
I understand this is kind of an edge case, but having the possibility to use signed ssh keys would be very useful to me.

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.

I removed the footnote form the 2.2 branch. Thanks.

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

FWIW, the second listed commit is the right one. You should only look at the STABLE-STABLE-2-2 branch. master and that branch differ; in particular we do not have a cut-off date in master (to be 2.3).

No need to support it. What I had in mind was the compilation of tiger.c where we replace optimization flags by -O1 which, as you remarked, seems to b widely portable.

The particular part of mkheader compilation with -O0 was introduced by dkg for cross build support.
I believe that -O<number> (where <number> is not zero) is common but -O<something-other> is dependent.
Requesting non-optimization by -O0 seems GCC specific.
(I grep-ped autoconf-archive and observed the use cases of -O0.)

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

Well, that was probably from the time I wrote that tool.

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.

As a user I think that this capability would be a great addition to PGP and it might even make it a standard tool for key generation across cryptocurrencies.

(Found while trying to answer a user question at http://wald.intevation.de/forum/forum.php?thread_id=2140&forum_id=21&group_id=11)

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?

Please do not do such changes after you found a solution. I assume this was some kind of error you won't further explain. Better just close it as invalid.