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.

I found a problem of possible duplicate registration of another APP, due to no serialization for CARD access.

The resource leak was fixed in: rG40707c8bff49: agent: Fix resource leak for PRIMARY_CTX.

This has also been reported at https://bugs.kde.org/show_bug.cgi?id=477798 (although there a crash occurs). Porting the command to gpgme didn't help, but the remaining problems are in gpg and/or gpgme.

Thanks.

If 7z is used to create a tarball that tarball is then 7z compressed. At least this is how I understand the case.
When gpgtar now tries to extract the file it sees a 7z file and thus emits the octal number warnings because it assumes a tarball (after decryption by gpg).

This problem was also reported at https://bugs.kde.org/show_bug.cgi?id=479567#c1

Fixed and backported for VSD 3.3

I'm now using the name "Compliance Check" for the test if no compliance is active/has been configured. I have also checked all other usages of DeVSCompliance::name() in libkleo and kleopatra to make sure it's only used if compliance is active.

While reviewing this task I noticed that I wrote adding a -p option. This is non-sense, because -p is to preserve permissions at extract time; this is unrelated to the last modification time. Standard tar extract files and set the modification to the one given in the tarball - unless you use -m to use the current time. Thus this task is actually a bug and not a feature request. For backward compatibility this will be done only for gnupg26 for now.

This ticket is obsolete, we did some work on gpgtar since then. Should the issue still occur, please reopen or create a new ticket

I have reverted the commit mentioned by Carl and another text codec related commit for the Qt 5 builds. This will hopefully fix the broken umlauts in the progress messages.

Fixed and backported for VSD 3.3

If compliance is not active, the self-test dialog now shows the test for compliance with just "?" as the test name

Tested with Gpg4win-Beta-70: works for changing expiry date as well as key creation