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.

Done ! Thanks.

I'm not actually sure how workflow should be on the 'patches' interface at dev.gnupg.org.

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?

Hello World

Hello World

Hello World

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.

Fixed with: https://commits.kde.org/libkleo/245eff174331c49264d1248c529e0276e02e9e29

Thanks for the report. Indeed I can also reproduce it with my own key. For signatures from expired / revoked / disabled keys it shows "No public key" because GnuPG returns the same error in that case. We can fix that by looking up the key ourself.

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.

We will do a new release in two or three weeks.

Dear Andre, LO team is not able to integrate your fix unless a new release of GPGme is ready. Usually you do that every half year or so, but sometimes the delay is much less (e.g. 1.11.0 and 1.11.1). Perhaps, you would find it possible to roll out a minor version of 1.13.0 to ease the suffering of international users a bit earlier?

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:

@sapienza Can you try it with Kleopatra please and if it fails there, too please post the "Diagnostics" from Kleopatra. (See "Blocco note" in Kleopatra for the same functionality)

One of the things that dirmngr has going for it is that it tracks the current network state, and it would be nice to be able to reuse that state across sessions. If an ephemeral keyring can't use a shared dirmngr, there are fewer arguments for having dirmngr in the first place, and people might be more justified in replacing it with things like https://gitlab.com/anarcat/scripts/blob/master/openpgp-key-get

Did you encrypt to a key of yours? You can only decrypt if you have the matching secret key for the public key you used for encryption. The error message: "No secret key" should be obvious.

Anglocentrism smells like a relic discrimination in our age of Unicode, let users name folders as they natively see the world. For example, a Greek/Russian/Turkish carpenter with calloused hands, who stores his chisel and hammer in a toolbox, might want to store computer tools like GPG or LibreOffice in a folder Εργαλεία/Инструменты/Araçlar (=Tools), but particular tool unexpectedly says “Error!”, which might be perceived as passive-aggressive “No, I was made to serve the needs of English-speaking celestials only”. Thanks to Andre Heinecke and Egor Pugin for sympathetic attitude and prompt steps to solve this issue.

Looks good, thanks!
I think they (LO) will catch up with the next gpg4win or gpgme release or smth like that.