Fixed for 2.2.9.

To be released with 2.2.9

Some times I a curious and it seems that GnuPG can be used on 32 bit Cygwin. Thus I wonder what is going on on 64 bit Cygwin (which I don't know). It might be a HANDLE/socket issue where Windows is still using values which fit into a 32 bit integer but Cygwin might have changed that. Eventually we need to remove that assumption in GnuPG's code and this is why I won't have a problem to keep this bug open.

Note that Cygwin is not a supported platform. Seems that the exec functions don't work on this 64 bit variant.

re: last question: Marking a notation as recognized does not mean gpg does do anything with it or that it demands this notation. The latter can be handled by the caller. For example, gpg knows about "preferred-email-encoding@pgp.com" but does not apply any semantic to it.

No problem. I am glad that it works.

Actually the --locate-key command differs from the implicit use of locate key code when encrypting to a mail address.
After importing the expired key and running for example

Won't fix for 2.2 or CFB encryption.

My bad. I looked at the wrong working copy. Will pick that commit.

Thanks. The entire getkey.c code better needs a complete overhaul for before we add v5 keys.

We have a workaround thus lowering the priority.

It seems @gniibe fixed that en-passant in master. At least I can only replicate this with 2.2.

next week?

The comment is a bit misleading. It does not fix the crash because it all depends on the stack layout: printf takes the args from the stack and if there are not enough args pushed by the caller printf happily uses args which are the local vars from our printf function. Clearing a few vars there seems to have the effect that the args for the "%s" now points to a NULL. In fact you can't fix such crashes with any stdarg function on any platform I know. That is why gcc as a couple of helpful attributes to detect misuse of stdarg args at compile time (e.g. sentinel, printf).

It won't import that keyblock. We can fixup some trivial cases but there will always be ways to create a garbled keyblock and that is nothing we can fix. Better restore the keyblock from a backup or write a dedicated tool fsck-like tool.

Printing "(null)" is just coincidence because NULL is stored at the respective stack address on one platform.

The patch fixes a symptom of wrong format specs usage. What happens with %s with no supplied arg depends on the platform and what is currently on the stack. So it will always be incorrect and you can't do anything about it except for letting the gettext tools checking the PO files for correct format specifier usage. In the english version gcc does the check.

Fixed for master and 2.2.9.

We didn't found the time to organize it. There will be a OpenPGP summit this fall organized by Patrick, though

Will be released with 2.2.9

Fix will also go into 2.2.9

Do you have Tor or the Tor Browser running? Dirmngr will use them instead of a direct or proxy network connection. Di disable this behaviour put

no-use-tor

into dirmngr.conf. If that is not the case we need some more debug info. Put

log-file SOMEFILE
verbose
debug network,dns

into dirmngr.conf and post the log file (or send privately to wk@gnupg.org mentioning T4044 in the subject - no HTML please).

Backport done. To be released with 2.2.9.

I am not sure what you mean by “keybundle”. Is is a single keyblock or a selection of multiple keyblocks?

The problem here is that we we did not sync the pubring with the secring in old version (2.1 removed the secring concept also due to that syncing problem). Now if we migrate (or plainly import a secring.gpg), gpg does not see any updated self-signatures and this is the reason why outdated self-signatures are used.

Done for master. Needs backport.

I implemented it in master and if you agree I will backport it to stable. This is the new output:

Not really. off_t is a real portability problem and this why we moved that problem out of the GPGME ABI to the application. Thus the application needs to care about mapping gpgme_off_t to whatever off_t it uses. Without that we can't provide a stable _and_ toolchain independent ABI.

We should include the man page then in texi format into tools.texi

Thanks for forwarding.

--shows-keys is not a debug command to show the inetrnals of an OpenPGP message. It does the same as creating an empty homedir, importing the keys and running -k. Thus there is no way to get to the internals of an OpenPGP messages.

See T4012 for a patch to build with an older libgpg-error.