What is the output of

gpg-connect-agent --dirmngr 'getinfo dnsinfo' /bye

and what is the content of your /etc/nsswitch.conf and /etc/resolv.conf ? Is there anything special in your /etc/hosts? Are you using any kind of non mainstream DNS resolver on your system or network?

That is likely "host not found" or "domain not found". Maybe a problem with your resolver. Please add

Fixed for 2.2.5. Thanks for the report.

This looks more like an Enigmail bug. In particular the manual start of gpg-agent as described in the workaround is useless because gpg-agent is always started as needed. I don't know your OS and thus I do not know whether gpg-agent is used in --supervised mode, as in Debian, or in the default way. What does

The first thing you should do is to write a proper bug reporting, including your OS, any special configiration you use (e.g. using a dedicated DNS sever) and the exact commands you give and outputs you see. Always use option -v with gpg. dirmngr can create a log file:

Despite that the use of a passphrase is entirely useless if a command like that is used, you need to add

--pinentry-mode=loopback

to the invocation. ( I assume you are using gnupg 2.1 or 2.2)

Andre, I assign this to you. If you don't think that a better warning in Kleopatra is needed, please close the report.

Thanks for asking. We may need to put this into the FAQ, so here is my answer:

Here is an extract of the log file which shows the assumed cause

The last line shows that gpg decided that to return a failure because the message does not use the MDC scheme. Since the introduction of modern algorithms with a _blocklength_ of 128 bit (e.g. AES) gpg always uses the MDC encryption system even if it is not announced by the respective key flags. The reason for theses algorithms are newer than the MDC system and thus we can expect that all applications supporting AES will also support MDC.

I guess that the MDC indicated a broken encryption or no MDC was used at all. Can you pleae run the decryption of the file on the commandline? Assuming that thar the file is msg.eml you do:

FWIW, the old format was only used up to PGP 2.3 . PGP 2.6 used the new format. This is actually more indication that the message has not been generated by an old PGP version.

Please explain en detail what you are trying to do and what the error is. Thanks.

Running tests with a modified keybox, so that the the keybox has only the meta data and the actual keyblocks are stored in separate files improved --list-keys by a factor of 10. This can be explained by reducing the size of pubring.kbx (which is sequentially scanned) from 95 to 2.5 MIB.

I added "futuredefault" as an alias and also made the matching case-insensitiv. Changing the rendering is not easy because using a non-breaking hyphen in @code{} would not look very nice.

It is

future-default

and not

futuredefault

Using an external process as an option is fine. However adding more dependencies to gnupg should be avoided.

I can see the case for encryption subkeys. Signing subkeys are still useful after their expiration.

All fixed (or marked fuzzy) except for master which will be done with the next merge from 2.2.

yes. That is the whole point of public key encryption. Please read one of the suggested intros or
ask for help at the gnupg-users@gnupg.org ML.

Well, I meant to do this on the command line (cmd.exe). Replace INFILE with the name of the encrypted file and OUTFILE is the name of the file which will receive the decrypted data. You can't do that in the clipboard.

It all depends on your system. This is why this is an _option_.

Can you please try to decrypt this message on the command line:

Okay, lets try with a default of 64. Note that for many concurrent ssh sessions you may also need the option --auto-expand-secmem which will come with Libgcrypt 1.8.2 and GnuPG 2.2.4

1.10.0 released

This is very likely dirmngr's DNS resolver which uses UDP by default. Fixies: a) use Tor. b) We add an option to use only TCP queries.

The fatal bug you reported can happen if the process is running out of secure memory. In general it should return an error but there is one place where we assumed the allocation would always succeed. This has meanwhile changed in the repo and will go into 1.8.2 However, this is not the real problem you have but just a wrong error behaviour.

mebibytes is not a spelling error but the correct unit (abrev is MiB).

Your comments in the output were hard to find. Thus my comment to explain the bug.
You are using non default options and in particular the hmac binary check. The latter was written a couple of years ago for an older Redhat version and it might well be broken in the meantime.

Which libgcrypt version are you using (gpg --version shows it)