AFAICS this is now implemented. We have the option --with-key-origin and even support in GPGME.

Done. To be released with 2.2.10.

FWIW, we record the origin of the keys. So you have the information. Use --with-key-origin in a key listing. GPGME also has the info.

Okay, can you please provide sample data for the test suite? Best using one of the existing keys but adding another one won't harm either.

No response so closing as invalid.

What are we going to do with this report? The last comment is 6 months old; can we change from testing to resolved or do we need to wait for a gpgme release?

I need to know which of the processes segv: mkdefsinc, cat or the subshell. And a backtrace would also be very helpful.

@kallisti5: For you server you can add only_urandom to random.conf when changing to a multiuser runlevel and remove it early at startup and termination.

/dev/random, RDRAND, etc involves a lot of political arguments and thus it is not easy to decide what to do. What you are calling for is a linux kernel specific code path (note that rndlinux is used by most Unices) and won't be helpful for other OSes. I am of course willing to do add specific for for a few widespread OSes (and in any case for Debian). It is a major change and thus does not belong into 1.8 - I am fine with master which Debian might want to backport.

What are your use cases?

I don't think that GnuPG >= 2 can still be build with RISCOS. In any case it is such a minor platform that we are removing special RISCOS hacks when touching such code parts.

Do you say that the linker can't handle the standard common block feature? The only toolchain I am aware of which does not understand this is the Norcraft C compiler for RISC OS. And now also Clang building for iOS?

gpg-agent has a pinentry caling timeout - doesn't that trigger?
In any case we agreed that Debian takes care of systemd support because that is not an upstream supported configuration.

We are moving to use the yat2m from gpgrt (libgpg-error); thus the additional tag.

Deleting a user id is more or less useless. What you want is to revoke a user id.

CryptGenRandom is only used as an additional source of entropy and doesn't count towards our entropy estimation. Thus whether it is used of not does not make any difference. Our main entropy source is meanwhile the jitter based RNG. Thus your request will receive a low priority.

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.

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.