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.

Thanks.

The command -e does not require any further argument. As with most Unix tools you can either give a file or let the tool read from stdin or output to stdout.

In the texinfo document, which is opened, when invoking 'info gnupg', there is a subchapter called "Invoking GPG". In this chapter, commands and options are defined. This is the text I mean.

Thanks. That typo was already fixed in 2.2.7.

Hi, it's OpenPGP and the same Exchange server. Perhaps it has to do with
the "Unterhaltungsmodus" from the error message.

I'm pretty sure I tested this in the past using the Outlook.com web interface. The mails should show with an unknown attachment (the signature). I can't think of any changes recently that would have changed it. I'll check again.

Though apparently resolved back in May, this is what ultimately led to T4191 and was thus only properly resolved quite recently.

See T3505 for more in depth coverage of this issue. Essentially this is a duplicate under a slightly altered POV.

Confirmed that this is indeed fixed and made the (rather minor) change to the HOWTO that was needed. No changes were needed for the example script (decrypt-file.py).

This has now been tested on a 32-bit Gentoo VM and it behaves as expected with 32-bit system detection and creating keys with pre-2038 expirations working.

Commit 8613727f1ee985c3cfa2c815523312914f033ffd adds considerable detail on both the issues affecting compiling and installing a Windows version of the bindings and what it would take to actually resolve it.

Thanks for the report.

Well, -Wno-macro-redefined should silence the warning but Iwill add an undef before our macro definition. The snprintf macro is used to make sure the libgpg-error's own printf implementation is used.

Most options are not explained with --help. Right before the examples you see

NEWS for 1.33:

I don't think this works for me in that way.

Use that function as early as possible. The gpg-error tool has also be enahnced on Windows:

Thanks. In the meantime GpgOL takes it's language from the Outlook configured display language setting. I'll add support for override locale to gpgol so that the locale is set accordingly

Regession due to my commit 10 days after the last release. Thus no need to do a release.

Should we close this or do you want to investigate why the segfault happened after the error?

Thanks.

I ran it with GPGME_DEBUG and it errors out at
GPGME 2018-12-07 10:34:32 <0x19c43> gpgme_op_genkey_start:293: error: Invalid argument <GPGME>

Sorry, I am still not able to replicate it: