Good idea.

CancelIoEx is supported by Vista.

This patch changes all the logic of finish_lookup.
It should be only when secret key lookup.
D297: 785_sign-fix.patch has been changed to do that, and it was applied to the master.

Applied to master.

Fixed in master, applying D297: 785_sign-fix.patch.
If needed, it will be in stable 2.2 branch, in future.

What is the benefit of two subkeys?

Please remove the colon in the end as well, just like in the english version. Else it is shown twice (see screenshot).

Hi gniibe

I think it was a version problem.
I have now installed gpgOL (2.0.1) and gpg4win version 3
It's working.
Just that emails do not directly access "decrypt", but those that are sent from MAC arrive as an attachment, with ASC termination. I need to change the extension to PGP, decrypt, and generate a file without extension. Then I need to change the extension to EML and then I'll be fine.
Can you fix it?

I assume you installed gpg4win. Which version did you install? 3.0 is the latest.

article 13 states the inviolability of the home ;-)

I do like to read about historical facts, motivations, etc ... as far as I know 'g10' is related to artikel 10 grundgesetz...

Thanks.

I've got libgcrypt-1.8.1

Thanks, that is interesting info, I need to look into that.

I spoke with the author of onionbalance, and they said:

Just to inform that it is not a single problem.
I recognized exactly the same behaviour.
After terminating the gpg-agent task everything works as aspected (up to the next non-activity phase).
64-bit Windows 7 Enterprise, Outlook 2010, GPG4Win Version 3.0.0-gpg4win-3.0.0.

I'm not entirely sure whether it is due to low usage or little problems with the service, but it seems to work pretty OK. My primary concern is that as opposed to DNS based system, the onionbalance system requires my node to be running and available and as such constitutes a SPOF. Although I've cleaned up my scripts sufficiently, e.g network outage will make this service unavailable whereby the hkps pool will continue to function.

Raising priority so that we have a chance to review this for the next 2.2 release.

Closing due to compiler error.

No info received and thus assuming that the caching was disabled.

You need to raise this with the IETF OpenPGP WG. First we need it in the OpenPGP standard, then we can implement Something (tm).

It is on the same machine, as I mentioned manually deleting ~/.gnupg/private-keys-v1.d/* is a workaround I have to use, but it is not very user friendly.

Sorry previosly I asked for more slots for keys on token. But its not
needed one. I dont even know it is a valid request but

GnuPG by design uses latest sub keys so in your setup office and home one
of them is latest.

The use case is having 2 different hardware tokens - I have an opengpg card which supports 4096 rsa subkeys, and a yubikey which supports 2048 rsa subkeys. At work I need one, at home the other.

After reading PIV and using PIV token I understood how much simple and easy
GnuPG is by design. You guys rock.

Is it you are moving to new sub keys? if yes do we still need outdated old
subkeys? Is it safe to cleanup old subkeys?

Hi, currently to be able to use 2 different cards with 2 different sets of subkeys from the same primary key (home and work) I need to manually delete ~/.gnupg/private-keys-v1.d/* everytime I want to switch from the first card to the second.

I can confirm this behaviour in the production version:
Outlook Professional Plus 2013 (15.0.4953.1001) in a corporate network (32 bit)
Create new message, no automatic selection of PGP key, S/MIME support both enabled/disabled, sometimes it works (after a fresh start of outlook), but after some idle time creating and signing new messages is no longer possible, the key selection dialog opens, but then nothing.

@bluca I created a ticket for smartcard, so that this ticket can focus on the issue of available keys on host. If anything, please add comment to T3416: gpg should select available signing key on card (even with -u option).

@gniibe yes, I can reproduce the problem using -u.
But why does picking a UID force the usage of the first known subkey? Is that expected behaviour? Is there a relationship between UIDs and subkeys?