No more complaints thus time to close.

Fixed in master and 2.2.

I consider this bug to be solved.

MacPorts doesn't currently ship the bindings at all, but I'll see what they need to make that a reality too.

While this is now ideal for Debian, it may cause conflicts with other downstream vendors with slightly different needs to build their packages. In particular the FreeBSD ports and/or pkg system.

Thanks for the report.

Yes. Thanks! I'm at over 2500 S/MIME verify operations without a crash now!

Yes! Thank you very much. My test runs and my Outlook has verified 2500 S/MIME Mails without a crash.

The T4237 fix should also fix this one.

To avoid the drawback, we can put the logic of locating possible libdir in gpg-error.m4, instead of putting in the script.

The explicit check for a valid FD (in select) I mentioned above is commit 8173c4f1f8a145c4b1d454f6f05e26950e23d675

There is another argument for respecting the usage flags: it trims the admissible key space, if key ID in the PKESK packet is zero ('wild card') and thus all private keys have to be considered for decryption.

I'm currently looking at the CloseHandle in _gpgme_io_close:

Sure. I'll mark that to be added!

Btw I've checked that the errors are the same in T4111 and this:

Certificate though has a nicer connotation to it and definitely feels like it has the connotation of something to be shown off to other people and displayed on walls, which I really like.

Whoops, going to repost.

I disagree, and you don't have to try to convince me, the decision is with werner. I just want to give my opinion:
Bug compatibility is nothing esoteric or bad especially for a general purpose backend tool like gnupg. Being open to accepting broken input is a good thing because it will mean that we can get people out of a "broken tool vendor lock in".

Fixed it myself as I confirmed the leak with Dr. Memory.

i agree with @Valodim that it would be better to not have a warning at all for an attempt to decrypt from secret key whose public key has never been marked as valid for encryption. A strict failure there (as with a strict failure for lack of mdc) is a better scenario than a warning. If the user controls the secret key and they decide they want to be able to decrypt with it, they should be able to mark it as decryption-capable (if that's really what they want) and retry. But this is an action only for experts.

The same *cannot* be said for a subkey that is marked specifically for certification or signing, and not for decryption.

I understand the real world requirement for decrypting messages that have been encrypted to a revoked or expired key.

I've seen now four crashes in _gpgme_io_spawn. I've added tracing that shows that the CreateProcess itself is crashing. I do not see how this is possible. I'm printing the command line and the program name in debug output and both look fine.
The command line is also mutable.

I'm also seeing hangs. Sometimes with gpgsm running. Sometimes without it running.

It builds for me now. I had a mismatch with a to old gpgrt-config and did not properly set PKG_CONFIG_PATH

libassuan master fails to compile for windows against libgpg-error master http://paste.debian.net/1049534/ I think gpg-error.m4 ignores both sysroot and --with-gpg-error-prefix