Well, green is a shortcut on how to display the status of the signature. It came from the green frame KMail printed and it soley used to rely on that information. The idea was that gpgme tells you what it considers to be a good signature. Opinions and trust models meanwhile changed and thus we indeed need to update gpgme's suggestion.

The problem with mnemonics based on words is that they are language dependent and only a small part of the world is fluent enough in English to spell/use them correctly. Thus anything based on ICAO spelling (Alfa, Bravo,...) is a better choice than arbitrary words from one language. Even if that meas to write down a longer string. A CRC is of course very useful.

Last week:

• GnuPG 2.2.9 release

There should be only one instance of gpg-agent running per GNUPGHOME directory (i.e per user). Is this a systemd system where you started gpg-agent in supervised mode (e.g. Debian) or a regular system. What is special in your setup?

if that is the case config.{guess,sub} needs to support this and we should be able to handle this the same way as other Unix platforms.

Right, but requires extra code. The --quick commands try to reuse existing code and, iirc, that is the reason why a user id is accepted for --quick-add-uid.

The command line is an API and we will never break an API without a very good reason. If you didn't like that API you should have noted that on the devel mailing list years ago ;-)

The term “user-id” is used throughout gpg to mean some kind of user id beit is a name, a key id, a fingerprint, a keygrip, etc. See the section "How to specify a user id" in the man page. FPR is used if a fingerprint is required.

I am not sure wheat I understand your request. --quick-add-uid takes a fingerprint as first argument you _may _ use a a user-id instead but that is for consistency with all gpg commands. Using the fingerprint is always highly suggested.

Release done: https://lists.gnupg.org/pipermail/gnupg-announce/2018q3/000427.html

You are mixing gpgsm and gpg - they have different semantics: That github mirror under the top name of "gpg" might
be a reason for that confusion.

Commit rEbd5bcd2dd19ef0b1c3d33a3a388b537ba08a4eb6

it is not due to windows but due to the use of NTBTLS. I have the same problem here... and found it: We call es_fflush to let ntbtls flush its internal buffers but libgpg-error's estream module does no propagate this explicit flush to the cookie functions of ntbtls. Thus ntbtls gets stuck most of the time. I am not sure when this regression happened but it is pretty obvious.

I have logging to a socket always enabled. That may explain why I don't see that error on Unix.

Fixed for 2.2.9.

To be released with 2.2.9

Last week

• Bug Fixing in preparation of 2.2.9
• Finished pairing tool prototype

This week:

• Continue bug fixing.
• Office work

Some times I a curious and it seems that GnuPG can be used on 32 bit Cygwin. Thus I wonder what is going on on 64 bit Cygwin (which I don't know). It might be a HANDLE/socket issue where Windows is still using values which fit into a 32 bit integer but Cygwin might have changed that. Eventually we need to remove that assumption in GnuPG's code and this is why I won't have a problem to keep this bug open.

Note that Cygwin is not a supported platform. Seems that the exec functions don't work on this 64 bit variant.

re: last question: Marking a notation as recognized does not mean gpg does do anything with it or that it demands this notation. The latter can be handled by the caller. For example, gpg knows about "preferred-email-encoding@pgp.com" but does not apply any semantic to it.

No problem. I am glad that it works.

Actually the --locate-key command differs from the implicit use of locate key code when encrypting to a mail address.
After importing the expired key and running for example

Won't fix for 2.2 or CFB encryption.

My bad. I looked at the wrong working copy. Will pick that commit.

Thanks. The entire getkey.c code better needs a complete overhaul for before we add v5 keys.