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).

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.

Thanks. That typo was already fixed in 2.2.7.

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:

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

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

Thanks.

Sorry, I am still not able to replicate it:

Can you give me a reproducer on Linux. I am not able to reproduce it. What versions of gnupg and gpgme are you using (see gpa's about)

I am not sure what text you reference. Can you please explain?

ImageMagick version with that regression?

That is good.

Needs to be merged. (Note that Phabricator does not show the branch in the tooltip for commit ids.)

With master we can now do:

Just to stress it; I am in favor of allowing builds using other compilers. We allow this on Unix and so we should allow this on Windows as well. We should remember to use different DLL names to make it explicit that a certain DLL is targetting a specific ABI.

Another build systems does not solve your problem. If you want to support another toolchain, that is fine. But it can as well be done with the current build system. it is a matter of adding a new platform triplet to make sure we are not linking against different libc versions. In fact we can build all our code on a wide range of platforms with very different compilers, so supporting MSVC won't be a problem. Mixing them is a bad idea as can be shown by the usual cross-runtime malloc/free problems.

In this case the data is taken from a byte buffer, (unsigned char *). I can't see why iobuf_readbyte should be invoked here.

Regression introduced with 1.12.0.

Why not using PowerShell? Because --with-colons does not output the required hash? But that can't be the reason because Python has the very same problem. Using Python for scripts is anyway a bit of overkill.

If they really want to do that for Windows, they can use some database approach like Protonmail does it. This does not require any file structure.

Sorry, we won't implement a server for WIndows. No sane provider uses Windows for a large mail setup.