Fixed in 1.51, by introducing gpgrt_spawn_actions_set_env_rev, which assumes utf-8 encoding.

Fixed in 1.51.

Fixed in 1.51.

Gpg4win-Beta-75, works:

For Beta-75 it looks similar judging from my first tries.

Fixed for all branches.

I managed to get the same "loading certificate" message several times in a row on this test instance by stopping and starting Kleopatra in a row twice. After removing the Signature Card 2.0 this did not happen again in 5-6 tries, although I collected 2 lingering listing processes again (not both started on the same startup). Even import of a X.509 certificate worked.

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).

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.

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.

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

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

@ebo Thank you for your continuous testing.

Unfortunately, this seems not to have ended the sporadic hangs.
I just saw a hanging initial keylisting with gpg4win-beta-70 which has gpg 2.4.6

My fault: All my test had the relax flag set which is so common to me that I did not thought about this. So you fix is for the case that no flag has been set for a fingerprint.

(Please don't set a milestone tag for a fix to an already released version - we use the milestones to track done tickets). Use instead the branch specific tag so it ends up on the workboard.

@ikloecker : Thanks for investigating. Please note that gpg-agent is incompatible wrt LISTTRUSTED (2.2 vs 2.4). So, No data callback in IPC maybe expected with gpg-agent 2.4.

The last two usages of KIconLoader have been remove in kleopatra master. (libkleo was already good.)

Sorry, I've pasted the wrong link, I wanted to paste this one: https://lists.gnupg.org/mailman/listinfo/gnupg-users

Why would I turn to the Windows mailing list when I am a Linux user?

I removed a duplicated comment above.
Please do not duplicate information (no top posting) and keep your descriptions short and to the point.

"BTW, GnuPG 2.3.4 is a very old version."

In the story of my life, you are a mythological figure.

I reviewed this and there are actually two changes. The first chnage
is a simple string change from

Sorry, I don't understand your problem. Please explain what you did and what the (perceived) problem is. BTW, GnuPG 2.3.4 is a very old version.

Hello,
I have a hard time to agree that is the right thing for gnupg to throw an error if it successfully imported a revocation certificate for an expired key. This is a meaningful (and not useless) change even if the key is expired.

Tested again on linux with current master (at 18081e2ecf43de2be6ad5a7ca3384e1e2b66914d) and 2.2 (at 5c0383d558cc9112c4c0984a3b2a6c98b29a92ca) - still same behavior.

You should use gpg-agent's integrated ssh-agent. It is anyway much more convenient. I'll move this task to gnupg26, though.

Backported to 2.4 to go into 2.4.6

Was fixed in master with rG374195e741cf1c52daad6c07799d308c8a9f73e3 (bug tag was missing in the commit).

Fix backported to 2.4

works for 4win-Beta-64, too but removing vsd33, as this is already in vsd32

Backported for vsd33

Indeed, gpg fixes a long standing bug in that expired trusted-keys were not correctly handled. Thus this error message

I can still reproduce case 2 with gnupg 2.4. I have to check how my local setup differs from gpg4win-Beta-64.

I have confirmed that rA69069bc63e6b fixes the build on macOS.

When checking this out with gpg4win-Beta-64 I can reproduce case 1 (and of course 3) but not case 2:

Regarding triage: This is not widely encountered and a workaround exists

Passing ticket to werner to consider backports.

Also done for gpgsm in gnupg26 (master)

Thanks. Fixed in: rEd14c69a7f256: Avoid use of 'nullptr' for an identifier.

The C comittee is getting more an more absurd by adding new keywords. Breaking software for fun and funding. Workaround should be easy: Don't use the C23 option.