Please describe which features are missing.

Caching of the OpenPGP PIN while switching to and from PIV does now work in master

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.

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.

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).

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.

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.

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.

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

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.

The Name field in GnuPG needs to be at least 5 _bytes_ long. Given that UTF-8 is required for Hangul, a 3 _character_ name is at least 6 bytes long and thus passes gpg check. The Name field is also optional and the whole test can be skipped using --allow-freeform-uid.

Fixed in master and 2.2

Many cards have some printed information and I consider them important to avoid testing one by one all the cards from my pocket.
This I am really in favor of beeing asked to insert the respective card. The new text format private key files make it much easier to maintain this info

The description comes from gpg/gpgsm while the prompts are from gpg-agent. Thus if the agent has been started with the German local but gpgsm without a local this would explain the behaviour.

[When changing a bug to a possible FAQ item it should be resolved and not marked as invalid]

All output of Assuan data lines is percent escaped. That is obvious because it is a line based format. You need to unescape it. Either use command line option

--decode

in-line command

/decode

or use

/datafile NAME

to write to a file.

Although I don't use the ssh client on Windows I had to integrate the Windows ssh server into our release process (GlobalSign sent us a Windows-only token, for the new cert and so we can't anymore use osslsigncode). The ssh server is really stable and so it makes a lot of sense to better integrate our ssh-agent into Windows.

Figuring out the matching user id for a new key signature. Right, --import-options repair-key is the the default and does the same. However, it was also the major cause for the recent trouble with the keyservers because it tried to verify all signatures. repair-keys was made the default (T2236) because it seemed to be nearly for free - which was a false assumption. We should not use this option by default and only consider properly placed signathures as valid. This of course also means that a userid is required.

I see no reason to move required computations from the server to the client.

Release done.

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:

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.

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.

Fixed for 2.2.19 and master