that error means that the message was somehow corrupted during transfer. Are you maybe using ftp in text mode on a binary message for example?
You could ask your communication partner to send you messages in text (ASCII Armor) mode which is more robust.
In Kleopatra you can change that in Settings -> Configure Kleopatra -> Crypto Operations -> Create signed or encrypted files as text files.
On the command line you need to add "--armor" option.

In Wald someone reports that this also appears to happen when decrypting. https://wald.intevation.org/forum/message.php?msg_id=6377 Probably run-threaded will help to flush this out.

Even with the logging changes this still happens. I just retested it. Can't run Kleopatra on Linux with GPGME_DEBUG=9.

In FreeBSD, getrandom(3) became available, when getrandom(2) was added. <-- This is my theory.
If this is true, just use getrandom(3), not using getrandom(2) by syscall.

It became common, because many people now use larger keys.
For RSA-4096, three simultaneous connections for decryption may cause the failure.
In the experimental patch of D472: Limit active connections for gpg-agent, I limit gpg-agent to accept two connections only.

increment the counter is better done by the looping main thread.

This is an experimental patch. So, I just reuse SIGUSR1 to wake up "select"-ing thread by kill(2).
I put limit-active-connections 2 in gpg-agent.conf for the test with run-threaded of gpgme.

Agreed this looks like it should be made default behavior. This has affected many people I work with, and even with searching, this ticket never came up. I only found out about it by making a ticket myself. This issue looks like it has generated at least 3 tickets in this bug tracker, and the agent is raising memory errors during normal usage, which still smells like a bug to me.

Though not directly related to our issues, this bug report on the MSYS2 site reported by their users encountering trouble with GPGME provides additional weight to irreconcilable differences between MSYS2 and GnuPG:

So if your DNS resolver does not tell us the IP addresses, we can't do anything about it.

The usual reasons for corruptions of binary data are FTP transfers in text mode; or opening a file with a Windows editor.

NEWS are:

Got another reliable report in the Wald Forum about this. https://wald.intevation.org/forum/message.php?msg_id=6371&group_id=11

No I do not think so. Because that would already be currently the case. If you had a subverted Root CA of course you can attack. But we are only talking about CRL / OCSP here. A root CA that does not provide a CRL for certificate X is OK. As long as the Root CA that issued X issues a CRL for that. Well the usual CRL / OCSP denial of service is still possible but I don't see any subversion.

Interesting idea but it does not help against attacks because all root CA are considered equal (virtually cross-signed). Thus a single not checked root CA allows to subvert all certificates.

I wonder if the best thing here might be another flag in the trustlist to disable CRL/OCSP checks for a single root certificate chain. I had such a request in the Gpg4win forums. Someone had a single unreacable CRL / OCSP and had to disable globally all checks for all other certs, too.

yes. that's why i wrote it in '['-brackets.
but usually, in info-documents a synopsis is written about it.
I think that it's not self-evident, that "you can either give a file or let the tool read from stdin or output to stdout" and therefore should be written explicitly.

Adding the patch here.

Uhm, if this option is useful why isn't it default behavior?

Thanks.

T3530 describes the solution. In short: Put "auto-expand-secmem" into gpg-agent.conf.

The --auto-expand-secmem option is available in 2.2. and master for quite some time. It works if libgcrypt 1.8.2 or newer is used.

Not a bug :-). I should have read my own docs before starting a long debug session. The things is that the auto expanding of the secmem area is only done for xmalloc_secure and the internal MPI allocation functions. It is not dne for any memory which is allocated with xtrymalloc becuase those properly return an error to the caller. The idea is that if the caller wants to get an error back he has also the assurance that them memory is allocated in the non-swappable memory (i.e. not in the expanded parts of the secmem).

For my case, with $GNUPGHOME/gpg-agent.conf having debug-all, I observed that rsa_decrypt failes with 'Cannot allocate memory', after debug output of 'res'.
Reading libgcrypt/cipher/rsa.c, it is line 1439, where it calls sexp_build (MPI of PLAIN into SEXP of R_PLAIN).
I think that it does indeed memory failure here.
Having "auto-expand-secmem" in gpg-agent.conf, it goes well.

I can easily replicate this; it is a problem somewhere in the secure memory code of Libgcrypt.

Fix was released with 2.2.11

If you specify a pool of keyservers dirmngr selects a keyserver on its won from the pool. This is so that it can use its own heuristics to detect whether a keyserver is dead and then retry another one. Now the default is a pool and your specified keyserver.ubuntu.com is also a pool (of two servers). So if your DNS resolver does not tell us the IP addresses, we can't do anything about it.

In your second run you added the options after the argument (4E2C6E8793298290) so they won't have an effect. Anyway, I can't see anything from the output. My way to debug that would be to run gpg under strace:

Will go into 2.1.12 to be released next week.