@werner That begs the question: why can't quick-add-key re-use the same code that quick-add-uid is using?

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.

We do have a history of extending the API, no?

You seem to have reached the wrong page when searching for msys2

I should have :) Thing is - a fix could be made in a backwards compatible way. So I don't really see your point.

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

And FWIW: an inconsistent UI/CLI should be treated as bug - not as a feature request.

You completely ignore the fact that --quick-add-uid and --quick-add-key are not consistent.
It's not clear why one should require a fingerprint and the other allows the kind of "user-id" you just described.
That was the main point of this issue.

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.

From the man page:

--quick-add-uid user-id new-user-id
--quick-add-key fpr [algo [usage [expire]]]

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.

To clarify: I would like to see the targeting of keys be unified.
I see the following options:

About how the keys are actually stored on disk:

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

The matching error message and the similar keywords let me to miss that - indeed.

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.

Done for npth.

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

There were two things here:

Works for me now.

On another note. We might also want to reduce the clicks required when certifying a key. The "I have checked the fingerprint" checkbox is out of time. People will check it regardless and we can't force them to do it.