and by that bypassing all key source tracking as done by gpg. In any case searching by name or mail address on a keyserver should not be done - at least not by a GUI tool as used by non experienced users.

I agree that this is a tricky problem, but it should really be improved.

The problem is not to check whether there is a connection but on how to decide whether something is a pool or an explictly added single keyserver and how often should we try to connect or read from it. Without marking hosts as dead the auto search features won't work well.

@Valodim probably not so much as dirmngr might behave differently and not mark hosts as dead.

The proper solution is of course to use pkill instead of killall. SCNR.

I can attest to the "growing bit of popular lore": Roughly half the support requests I get to support@keys.openpgp.org boil down to an exchange of "it just doesn't work with a 'general error' message" -> "try killall dirmngr" -> "that did it". I have heard similar stories from @patrick from Enigmail users, and more than once heard people applying poweruser trickery like "I just have killall dirmngr in my resume.d".

Hi Andre, did you already get anywhere with this task? Thanks a lot in advance, Joachim

Yes, I need to optimize it.

Hi @slandden. Have you made any progress since the last time I asked?

It can force it on the outbound. https://support.symantec.com/us/en/article.tech164655.html
It also allow SIMME pass-through. https://support.symantec.com/us/en/article.tech166867.html

Implemented in master.

BTW, I just pushed some new features to maste for the gpg-card tool. You can now do

Is this about any special version of Symantec? As far as I knew Symantec Endpoint Security Desktop (or whatever they call it nowadays) supports reading PGP/MIME and even sending it if forced.

With new "KEYINFO" command of scdaemon, finally, we can move on to support better selection of signing key.
(Note: having a private key on multiple cards had already been solved in T4301: Handling multiple subkeys on two SmartCards.)

In master, it has been implemented.

The first "SCD SERIALNO" command let scdaemon re-scan smartcards/tokens.

With new "KEYINFO" command in scdaemon, a list of card keys can be retrieved by:

There is no use cases for $SIGNKEYID.

$ENCRKEYID use case have been removed.

The base64 for the version is not needed. I rebuilt and did a test for that. I was testing with Outlook 2016 to Outlook.com to another exchange server. One of the servers in the chain is converting the mime parts to base64.
The MAPI headers in gpgol are causing the auto-decryption of Symantec to stop checking for the MIME attachments. On internal emails the MAPI format is retained and that causes an issue with the symantec client. When they leave the exchange server the base MIME format is what is sent and that works with the Symantec client.

Using base64 encoding for a fixed format part in us-ascii is not a good idea because in practise many PGP/MIME decoders won't be able to detect and then decyrypt such a message.

$AUTHKEYID use cases have been removed.

I am wondering if there is any workaround or work in progress about this old ticket.
I understand this is kind of an edge case, but having the possibility to use signed ssh keys would be very useful to me.

As a user I think that this capability would be a great addition to PGP and it might even make it a standard tool for key generation across cryptocurrencies.

It has now been over 6 months since the patches were available to fix this problem and they have not been adopted upstream.

Considering the concrete use case(s), it is more rational to support listing by capability.