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.

Well, that is a detailed bug report. Thanks.

Form my understanding this needs to be fixed urgently.

Pretty obvious. Thanks.

Hmmm

I have a warning already in my working copy.

Well, it should not happen if you always use the same key.

There is indeed a race condition between the passphrase cache and the pinentry invocation. There is even a comment on this somewhere in the code. The problem is that we would need to lock almost everything to avoid this rare condition.

Which Libgcrypt version?

I fixed the gpgrelay link.

It is useful if you often log out and in, for example using remote remote ssh session. If you don't like it, you should "gpgconf --kill gpg-agent" in your .bash_logout. ~/.xsession or whatever your system uses. Instead of --kill you can also use --reload so that the passphrase cache is flushed immediately and not only at the end of the TTL.

Thanks. Just pushed the change to master.

Let me also note that gpg-zip was not installed since 2006 due a conflict with gpg1.

gpg-zip is deprecated because we have replaced it by gpgtar. Given that you have a workaround for Debian I tend to close this bug as WONTFIX.

I think there are some races in the crl updated code but no real harm.
To improve you patch we could write a wait_for_idle function which counts the active connections and the housekeeping threads. It would also need to block new connections etc.

It does not make sense to handle this in the protocol. The client should always ask for joe@example.org and thus keep the whole thing mostly out of gpg. This requires that keys are not created with sub-addresses. However, if someone has a need for this, this strategy should work:

Also consider that it is possible to change the key usage flags. Thus it will never be clear whether one has a fixed or unfixed public key. I'd like to close this bug because it is currently also discussed in the IETF WG.

gpgme_op_decrypt_verify can always be used instead of gpgme_op_decrypt. This is an obvious requirement because the signature and the fact that there is a signature is only known after the decryption step. The newer GPGME_DECRYPT_VERIFY of the gpgme_op_decrypt_ext function is basically an alias for gpgme_op_decrypt_verify.
For both functions gpgme employs "gpg --decrypt".

The dirmngr may at any time open a file in that directory and thus there is no reliable way to remove the home directory when any gpg tool is running. Daemons need to be stopped before a directory can be deleted. So I think this is a non-issue and brought to the table only because we have that kludge of detecting a n unlinked directory on Unix. But even on Unix this is not possible to get rid of the home directory, for example if you want to umount it.

Using intptr_t works with this particular case but it does not
solve the general problem under Windows. On Windows an integer
may identify a libc file handle, a socket, and some other
objects. Despite that they are integers they are all different objects
and it is hard to distinguish them

Please provide a complete build log or at least the output of the configure run.

Sorry, it didn't made it into 2.2.11.