Next I managed to have one gpg and one gpgsm process each left over from the last execution of Kleopatra.
After starting Kleopatra new anyway, again "loading certificate cache" and an additional pair of gpg and gpgsm listing processes start.

Had a occurrence of the never ending "loading certificate cache" issue again.
There was a leftover gpgsm process from the previous tests (although Kleopatra warned when I closed it, that processes still running in the background were there and would be aborted).

gpg4win-Beta-70:
The tooltips are all there now.
But some of the tooltip translations are missing and need to be merged/copied still.
So I'm moving this to backlog, so we do not forget this

works, gpg4win-Beta-70.

In T7379#193696, @ikloecker wrote:

I assume by "do such things in the background" you mean that GnuPG should do this automatically in the background.

SCD SERIALNO serialno can move the first card in the list in scdaemon.

I assume by "do such things in the background" you mean that GnuPG should do this automatically in the background.

@ikloecker Using scdaemon with multiple cards, it is a connection which holds the card.

Support for NKS (Telesec NetKey card and Signature card v2, both based on TCOS) is very old and predates the support for multiple applications. They are also not as well separated as with Yubikey applications. Thus the auto switching between the NKS app and the SigG app.

@ikloecker Thank you sharing the problem. I don't know much aboug NKS card.

The whole learn-card thing is more a hack than a solid way to make cards known. We should do such things in the background when a new card has been seen.

I cannot reproduce the crash anymore. I guess this was fixed with the fix of T7372: Kleopatra: Crash when unplugging smartcard while operation is in progress. I'll close this ticket as duplicate of T7372.

@ebo I suspect that we want to fix this crash also for VSD 3.3 (if it is still reproducible). I found this ticket by accident while searching for READKEY.

I haven't added any project tags because I'm not sure for which projects this is relevant. Since GnuPG 2.2 doesn't support multiple smartcards it's likely not relevant for VSD 3.3.

@gniibe It seems that a keylisting (with gpg and gpgsm) interferes with a READKEY --card --no-data -- NKS-NKS3.4571 gpg-agent command and makes it hang until scdaemon is killed.

It looks as if a keylisting interfered with a gpg-agent/scdaemon command.

48458.670390	2024/11/06 12:43:04.238	5772	kleopatra.exe	org.kde.pim.kleopatra: ReaderStatusThread[GUI]::ping()

^ update of the smart cards is requested

48458.670695	2024/11/06 12:43:04.238	5772	kleopatra.exe	org.kde.pim.kleopatra: ReaderStatusThread[2nd]: new iteration command= "__update__"  ; nullSlot= true

^ background thread starts update of the smart cards

48459.147743	2024/11/06 12:43:04.728	5772	kleopatra.exe	org.kde.pim.kleopatra: ReaderStatusThread[GUI]::ping()

^ another update of the smart cards is requested (the request is queued)

48464.804883	2024/11/06 12:43:10.393	5772	kleopatra.exe	org.kde.pim.kleopatra: ReaderStatusThread: Card "89490171500022806460" with app "nks" was added
48464.805095	2024/11/06 12:43:10.393	5772	kleopatra.exe	org.kde.pim.kleopatra: ReaderStatusThread: Card "D2760001240100000006154932910000" with app "openpgp" was added
48464.807483	2024/11/06 12:43:10.393	5772	kleopatra.exe	org.kde.pim.kleopatra: ReaderStatusThread: Card "D2760001240100000006154932910000" with app "piv" was added

^ the background thread completed the update of the smart cards and found three card apps

48464.811286	2024/11/06 12:43:10.393	5772	kleopatra.exe	org.kde.pim.kleopatra: ReaderStatusThread[2nd]: new iteration command= "__update__"  ; nullSlot= true

^ background thread starts another update of the smart cards

48464.924701	2024/11/06 12:43:10.492	5772	kleopatra.exe	org.kde.pim.kleopatra: ReaderStatusThread[GUI]::learnCardsCMS()

^ learn cards is requested (and queued) -> Kleopatra shows the progress overlay

48465.796319	2024/11/06 12:43:11.291	5772	kleopatra.exe	org.kde.pim.libkleo: KeyCache::RefreshKeysJob start

^ a keylisting is started (OpenPGP and S/MIME)

48467.549251	2024/11/06 12:43:12.874	5772	kleopatra.exe	org.kde.pim.libkleo: sendStatusLinesCommand "SCD LEARN --force" : got ( status( "READER" ) = "SCM Microsystems Inc. SPRx32 USB Smart Card Reader 0"
[...]
48467.550423	2024/11/06 12:43:12.875	5772	kleopatra.exe	org.kde.pim.libkleo: sendCommand "READKEY --card --no-data -- NKS-NKS3.4531"
48467.895485	2024/11/06 12:43:13.187	5772	kleopatra.exe	org.kde.pim.libkleo: sendStatusLinesCommand "READKEY --card --no-data -- NKS-NKS3.4531" : got ( )
48467.896400	2024/11/06 12:43:13.188	5772	kleopatra.exe	org.kde.pim.libkleo: sendCommand "READKEY --card --no-data -- NKS-NKS3.45B1"
48468.209551	2024/11/06 12:43:13.471	5772	kleopatra.exe	org.kde.pim.libkleo: sendStatusLinesCommand "READKEY --card --no-data -- NKS-NKS3.45B1" : got ( )
48468.209660	2024/11/06 12:43:13.471	5772	kleopatra.exe	org.kde.pim.libkleo: sendCommand "READKEY --card --no-data -- NKS-NKS3.4571"

^ the background thread sends multiple commands to gpg-agent to gather information about the smart cards
^ the last READKEY command seems to hang

48468.598283	2024/11/06 12:43:13.822	5772	kleopatra.exe	org.kde.pim.libkleo: Kleo::KeyCache::RefreshKeysJob(0x63ccba8) RefreshKeysJob::done

^ the keylisting is done

Backported for VSD 3.3

Canceling the password prompt is now handled correctly, i.e. the operation is aborted without further feedback.

ok, looks good, Gpg4win-Beta-70:

Ok, gpg4win-Beta-70. Looks like this now:

This works with gpg4win-beta-70.