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

We need more testing.

We had this idea to have a label: or similar item in the extended-key-format which is displayed in addition to the other info. The user can then use an editor to put whatever she likes into this field.

It actually tries several servers but we need to set a limit because we need to cope with longer timeouts. Do you suggest to toggle between v4 and v6 addresses? That is if a v6 address fails, first try the next v4 address and it that fails, another v6 address, etc.

I don't see a problem. If you have the private key you can and will use it. I guess your concern is an oracle?

IIUC, in Gentoo multilib (or other distributions), <triplent>-{gpg-error,libgcrypt,libassuan,npth,libksba,npth}-config script is used.
In forthcoming libgpg-error 1.33, single gpgrt-config is used for all architecture, by having --libdir option at invocation time.

New gpg-error.m4 detects gpgrt-config, too.
And configure supplies --libdir when it invokes gpgrt-config.
For other *.m4 (libassuan, ksba, libgcrypt, ntbtls), it is possible for them to check GPGRT_CONFIG to use gpgrt-config if any.
For npth.m4, it can do that too, with no hard dependency to libgpg-error.

I decided to change gpgrt-config to have --libdir option.
By supplying libdir directly, it's no need anymore to detect the directory by CC variable.
gpg-error.m4 is also updated.

Thanks.

Fixed in master and 1.8.
@dkg: Thanks for the comments and your patience to convince me.

The next step is to release libgcrypt 1.8.4 :-)

I need more information:

• where is pkg-config path for <host_alias>? How is it determined?
  • 32-bit: /lib or /lib32?
  • 64-bit: /lib or /lib64?
  • something like x32: where???

I consider:

• Single gpgrt-config is better (and simpler)
• new option --for-host=<host_alias>? (--host is already used for query for host)
• update *.m4 using this new option to provide host information to determine the path

Actually we plan to provide a more convenient way to perform the DH operation. See for example P7 for the non-elegant way which is required today.

Fixed in master and 1.8 by detecting a fork and re-opening the devices