This has been fixed in the meantime. If you should still experience this problem with Gpg4win 4.4.0 then reopen this ticket.

Gpg4win 4.4.0 has just been released. I assume that this has been fixed in the meantime. In particular, "General error" should happen a lot less. If the problem still occurs with Gpg4win 4.4.0 then reopen the ticket.

This ticket is obsolete

I assume the problem has been resolved because we never got feedback that the problem persists.

This problem has been fixed quite some time ago. See https://bugs.kde.org/show_bug.cgi?id=415168.

This doesn't look like a problem in Kleopatra.

We won't revert to the old UI which had its own share of problems. In the meantime Kleopatra supports certificate groups which should help if you often need to encrypt for the same keys.

I get this message even with --quiet:

Fixed in 2.5.0 and 2.4.6.

Fixed in 2.5.0 and 2.4.6.

Fixed in 2.4.6.

Fixed in 2.4.6.

Fixed in 2.4.6.

I believe this was fixed by T7386. Or it is now no hard lock up by T7402.
So, let me close this ticket.
If any new symptom, please add information into T7396.

Gpg4win-Beta-94: works

Well, T6893 was removed from this release, at least for the windows builds, therefore this ticket can not be tested on windows for vsd33

tested with Gpg4win-Beta-75++

For this ticket, I reviewed the code around my SOS changes.
Because I'd like to focus the point of retaining binary representation when doing import->export,
I created another thicket: T7426

For master fixed with rGbb6b38c24010258c7cb2da840d0a088fe43393b3 (Wrong bug id used).
Also fixed for gnupg24.

Gpg4win-Beta-75++

tested with Gpg4win-Beta-75++

Fixed (for Gpg4win 4.4 / VSD 3.3) by patching Qt's Windows Vista style.

Perfect, thank you!

You are right. Printing the algo was missing in gnupg22.

thanks for the clarification. i was not objecting to the workflow, i was trying to understand so that i can interact with the bug tracker appropriately. I was unaware of the difference between "milestones" and other project tags. I'll try to get that right in the future.

Please do not add milestone tags.

gnupg24 (gnupg-2.4.5) is a milestone and means "fixed in gnupg24 (gnupg-2.4.5)". I suggest not to question the workflow of the people running this bug tracker.

@ebo i'm not sure i understand why you removed the gnupg24 (gnupg-2.4.5) project label. the report indicates that GnuPG 2.4.6 at least (other versions untested, but i didn't see a gnupg24 (gnupg-2.4.6) label in this system) produces MPI artifacts for EdDSA/Ed25519 signatures that are non-compliant with all the known specifications. the 2.2 series appears to retain compatible MPI formats.

with no real world impact.

This is not a bug in 2.2, this is a bug in 2.4.

2.2. reaches EOL in 6 weeks and thus we won't look at a potential problem with no real world impact.

after a bit more testing, it looks to me like 2.2.45 will revise the signature packet to use 0x00ed as the MPI header for r, if it receives input from 2.4.6. And 2.4.6 will revise the signature packet to use 0x0100 as the MPI header for r. So the same OpenPGP self-sig will change shape each time it is passed back and forth between the different versions.

@ebo Thank you for your testing.

@ikloecker indeed we try only for 5 seconds:

I think that the card reader is not connected and there is no Scardsvr at this time.
And the card reader connection to USB port results invoking Scardsvr. Then, "SCD SERIALNO --all" gets success.

For T6567 I changed the way that Kleopatra runs "gpgconf --launch gpg-agent". This change is not yet in Eva's test build. It seems my change is not good because running "gpgconf --launch gpg-agent" timed out after 5 seconds in 3 of 3 tests starting Kleopatra after a reboot of the VM. To check if "gpgconf --launch gpg-agent" really takes that long I measured the time in PowerShell after another reboot of the VM. The result is shocking.

Please note that a card insertion to a card reader and a card reader connection to PC are different things.
It may cause different results.

ebo: Thank you for your testing.

I found an issue in libassuan, which might be related possibly, it is described in T7399.
When the response is not consumed like the case in T7399, if repeatedly, it may fill up the buffer eventually.

This was fixed in gpgme and is therefore automatically in VSD 3.3

I believe this is a case of non-consumption of client. on Gpg4win-Beta-75 + updated GnuPG.
Setup: I had two cards connected, one Yubikey and one Netkey3.0 card. I rebooted windows and started Kleopatra. Nothing else.

This is included in test installers since some time already.

This change is also used for VSD 3.3

The same CSS has worked for years. Suddenly, after an update Firefox started to misbehave. I don't know if it's actually a bug in Firefox or in fontconfig or something else, but it's certainly not a problem of the CSS.

This website uses this CSS rule for body:

Works, you now get an error message that the card can not be found.

I put "scd" tag and let me claim this ticket.

The symptom of this bug was:

• there are multiple waiters for COND.
• COND is fired by npth_cond_broadcast, all waiters should be waken up, but only one wakes up by the old code of 1.7.
• other waiters keep waiting forever.

After I fixed the problem, I realized that the description of this ticket was not accurate, so, modified.

That's a bug in Firefox. Chromium doesn't exhibit the problem. I have problems with fonts in Firefox on many different websites.

This seems to be QWizard-specific behavior. One more reason to port away from that

FWIW, we should eventually get rid of the pipe + socket style connection model. It is just to complex with no real benefit.

After fixing two bugs, I changed the title to express the scope of this ticket.