nice, i'm glad to hear you've got something working, @matheusmoreira ! if you can point to your branch, or send patches here so that other folks can review, that would be great.

Ha, fancy that, I just added the method of using gpg-connect-agent to our new handbook, I agree that having a --delete-secret-subkeys command would be incredibly handy here.

I managed to make it work on my branch: gpg --delete-secret-key FPR! deletes just that key and no others! I will prepare a patch for this specific change and then try to implement the --delete-secret-subkeys command.

Screenshots were sent by e-mail to you. Thunderbird and Outlook screenshots are different.

I am quite sure! Because, (1) I opened both mails on another computer were Thunderbird is installed. Both signatures can be verified on both accounts with Thunderbird. Both mails were sent out with PGP signature by HPI Identity Leak Checker Team, so the signature generally works fine. (2) If I save the key which is as asc file in the attachment (in the account which does not work) on computer and perform then a check of the signature, I receive a input / output error in Kleopatra. I will make some screenshots, and I´ll send it by mail to you.

Are you sure that it is related to accounts and not to the mail? E.g. if you copy that mail from the second account to the first account, is it verified then?

FWIW, with 4a130bbc2c2f4be6e8c6357512a943f435ade28f I fixed a similar report by @syscomet but lacking a test case this was a blind flight ("This patch is not tested but a good guess."). Thanks for tracking it down.

Minor

For reference our downstream tracker of this is https://bugs.gentoo.org/683254 including patches

The patch touches src/Makefile.am. You need to run automake to update src/Makefile.in.
In the patch, it uses pkg_namespace variable to have prefix 'errnos_'.

Paul Wouters writes to me:

I just noticed that dirmngr(8)'s documentation for its --keyserver option says:

Note that even sending a HUP to dirmngr, when it is in this autodetection mode that observed tor at the start, is insufficient to have it re-run the autodetection. You have to explicitly terminate dirmngr to get it to unlearn the autodetected presence of Tor. This is subtly hinted at in dirmngr(8), but no justification is given for it.

I think I identified the bug. A fix is pushed.

Before the SEGV, calling a handler in _gpgme_io_close is strange:

GPGME 2019-04-11 12:24:58 <0x660e>        _gpgme_io_close: check: fd=0x22 invoking close handler 0x7f341d8b8960/0x7f33f0003930

Because the file descriptor 0x21 and 0x22 is allocated by _gpgme_io_pipe, and there should be no handler(s) for those fds.
Either, the notify_table is screwed up, or there is a leak of fds.
I'd like to see the logs of all calls of _gpgme_io_set_close_notify and _gpgme_io_close.

Sorry, I overlooked. I think it is inside _gpgme_io_close calling the handler, and the handler segfaults.

I have a fix. I'll commit it later.

Apparently, it SEGV-ted itself by assert at line 468 in gpgme/src/engine.c.
For GpgSM, info->file_name is not assigned (while it is done by gpg and gpgconf).
The code hasn't been changed for a while, I don't know the exact reason why it becomes occur.

Fix is ok for oss-fuzz

I think that the bug has been there. The commits of import.c revealed the problem with your particular input.

Thanks for your report. It was good you add "enter no passphrase for Alfa Test Key". Then, I saw the leak. (I misunderstood as if I needed the test environment.)
Anyway, I'm going to fix it now.

Can you see the problem and fix it with the given information?

Added a fix to GnuPG, too (master and stable 2.2).

I've been studying the source code. When a fingerprint suffixed with ! is given as argument, the [do_delete_key](https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=g10/delkey.c;h=cc567384612ccf0dfd41d9e620d6cd5e759fd7b6;hb=HEAD#l50) function correctly classifies the search descriptor as exact and finds the correct key using [keydb_search](https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=g10/keydb.c;h=8c067e1dfbfa7a6394e44dbed3bfaef5a4fa7c43;hb=HEAD#l1853). However, the handle returned by [keydb_get_keyblock](https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=g10/keydb.c;h=8c067e1dfbfa7a6394e44dbed3bfaef5a4fa7c43;hb=HEAD#l1352) apparently includes the primary key and all subkeys associated with it. After confirming the action with the user, the function iterates over all PKT_PUBLIC_KEY and PKT_PUBLIC_SUBKEY packets present in the keyblock, obtains the keygrip of each key and asks gpg-agent to delete it.

I keep this ticket open, since it is also problem for other packages.

By installation from version 2.3 an error occurred, I´ll send you a screenshot by e-mail. However, I have some comments to the current version which may also help: I have three keys, two on smart cards and one on a Yubikey. So long as only smart cards are used, it is no problem to change between the cards and they work fine. Problems occur, if a Yubikey comes in. (i) Not always a Yubikey is recognized by pressing F5. (ii) It the Yubikey is recognized and next a key from a smart card is needed, a computer restart is required.
I tried also command: gpgconf --kill gpg-agent
It was possible to change from smart card to Yubikey with the command. However, if the Yubikey 5 NFC was recognized, the only way to change back to the smart card was a restart of the computer.

I did that. It felt like it took longer for the error to appear with debug output enabled, but that is probably subjective/random noise.

Can you please run claws like this:

I've tested it with Gpg4win-3.1.7, too and it works for me so something must be special.

this error comes to me when I try to decrypt a message and I get this message

Unsupported protocol still means something with your GnuPG installation is strange.
Whats surprising me most here is that Kleopatra works for you.

I would be interested to here if it worked. But for now I'm closing this as resolved as there is no obvious next step.

We do not support 64 bit Windows thus this problem on Cygwin is obvious. Funny that Cygwin falls back to native Windows object in this case.

For what I use, please refer: https://tracker.debian.org/pkg/gcc-9

I´ll give it a try for sure! Probaly next weekend, so my feedback will be sent next week. Please, keep the file open. THANKS

I'm interested if this works as you imagine with 2.3 I'm pretty sure werner worked on a problem like that.

I've looked into it alot first: If I use outlooks builtin S/MIME support it also does not work for me, at least over SMTP. I see the attachments but they have unknown type and if I double click them I get errors.

This was fixed afaik in 3.1.7 please let me know if this still does not work for you.

After re-start, the smart card will be recognized in proper way and it works. I assume it has something to do with using Yubikey and smart cards with different keys alternatively. The Yubikey was not found originally, so I modified the following:

2.3 Release plan is around this summer. There will be a public beta sooner.

Kleopatra recognizes the smart card, shows the correct version number and keys in the "smart card - management" window. In the Keylist I can´t find the key. Currently GnuPG 2.2.15 is installed. Do you know then version 2.3. will be released?

For Kleopatra there is a "TODO" to better handle multiple smartcard readers. E.g. that you can have mutliple tabs in the smartcard management view.

Well, I can narrow the root case. A Yubikey 5 was successfull installed and can be used. Then I started to test the OpenPGP card. I recognized, that by pressing F5 in Kleopatara a change between YubiKey and Smart Card happens. However, if I test it via command line, Yubikey does not change, although it is dismounted and the smart card is inserted. Probably therefore, the private key cannot be found. It should be mentioned that I have a computer with integrated smart card reader. First I configured the card, then the Yubikey. I started to test the Yubikey first. Therefore, I believe it is a mess in detection of smart card / Yubikey if used parallel.

Which one version gcc 9 you've been using?
May I see gcc -v ?

And please do not use Gpg4win 3.16 but the bug fixed release 3.1.7.

Please explain in detail what you did to receive this error message.

@gniibe already wrote: “With gcc-9 in Debian experimental, everything goes well.”

BTW: fedora corp provides already free access to build envs with gcc 9 which can be easily integrated with CIs.

What you mean " it is not reproducible for u"?
Did you try to use gcc 9 and you had no problems compiling gnupg or you don't have access to build env with gcc 9?
Try to google to "gcc 9 pragma" and you will find several discussions and patches done by people fixing similar issues.

@kloczek , it is not reproducible for us, so, we consider it may be a problem other than GnuPG itself, possibly, some specific build configuration parameter(s) for GCC, or something by unreleased code.
Please file a report with how to reproduce your problem.

Why do you think that it is gcc bug?

So this seems to be a gcc bug, right. Then we should close this bug.

This is largely solved.

I think commit https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=09c27280cc09798d15369b3a143036b7ab5ddd69 should be backported to 1.8 branch of libgcrypt.

HTTP/1.1 spec, RFC 7230, Section 5.4, paragraph 2:
https://tools.ietf.org/html/rfc7230#section-5.4

Please be so kind and point me to the specs stating that you should put the IP address into Host:

It's up to GPG to send the Host header that shows the user's intent.

So in short you want:

1. Allow to specify a keyserver by IP without any DNS lookups.
2. When connecting via IP use the IP address for Host:.

With the downstream report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925952 I resolve this here.

Thanks for the report. This was fixed with: https://cgit.kde.org/libkleo.git/commit/?id=8a94ac0835f0cff8908943d2a630a003a3429220 which I backported to Applications 18.12 which is the current stable release. But debian needs to add this patch. I'll report a debian bug and link it here.

Good that it works again for you.

I don't anymore think that it makes sense to fix it. Further there is no cache for PINs; that is entirely up to the card.

This was most likely a (chipcard) hardware issue. It went away after polishing the contact pads for a bit. Possibly my laptop reader applies more force...