I made it optional for now with default on. So that if it crashes it can be disabled. We need to see if the crash is a general problem or a special problem of that one tester.

This was fixed with kleo rev 289efa360f6b15a3389ea2f2efede352711e7d7e

We disabled the codepath that required this for now. Lets see how it works.

I can't reproduce this. When I make Dirmngr offline I correctly get a No CRL known error. So it must be something different.

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.

While performing some initial investigation regarding observed discrepancies between compiling GPGME directly and the subsequent SWIG static object for T4086, confirmed the relative ease by which multiple installations would be achievable if performed as a post-build process. This would have the added advantage of being more readily customisable by package maintainers downstream and not just for Debian, it could be made to work more easily with other distributions or other posix systems too.

Obvious benefit will be:

• It will be easier for developers who use pkg-config for their applications, and want to use gpgme. They can use pkg-config for gpgme.

Since first observing this … annoyance … the following updates have been made: Emacs has been upgraded to version 26.1, Org-Mode has been updated multiple times, including significant changes to Babel and the XHTML export, python-mode has been updated, multiple variations on the source blocks have been attempted, the document has had any and all tabs stripped out and replaced, plus each code block has been refactored and re-entered multiple times.

I've now run the proposed patch on a GNU/Linux system where the kernel's RNG is initialized but /proc/sys/kernel/random/entropy_avail shows numbers below 100, and i can confirm that 3072-bit RSA key generation takes roughly 0.8 seconds: 20 sequential default --quick-keygen operations (each creating two secret keys) took ~32s.

Here is another example of users doing sketchy things to try to "fix" this process:

Here is an example of the kinds of UI/UX mystery that users face while this decision is unresolved:

I can't reproduce the problem with multiple instances of gpg-agent and scdaemon.
However, gpg-agent continues to run after the user has logged out. This is unacceptable, am I right?