Today
tested with Gpg4win-Beta-75++
Fixed (for Gpg4win 4.4 / VSD 3.3) by patching Qt's Windows Vista style.
Perfect, thank you!
[GNUPG:] BEGIN_DECRYPTION [GNUPG:] DECRYPTION_INFO 0 9 0 [GNUPG:] PLAINTEXT 62 1732178872 [GNUPG:] PLAINTEXT_LENGTH 72 You will be advanced socially, without any special effort on your part. [GNUPG:] DECRYPTION_OKAY
You are right. Printing the algo was missing in gnupg22.
Yesterday
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.
Tue, Nov 19
@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.
Mon, Nov 18
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.
Sat, Nov 16
@ikloecker indeed we try only for 5 seconds:
Fri, Nov 15
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.
Thu, Nov 14
This was fixed in gpgme and is therefore automatically in VSD 3.3
I believe this is a case of non-consumption of client, I had two cards connected, one Yubikey and one Netkey3.0 card.
Setup: 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.