Regarding the "unsure" findings:
- invalid state in cert list tooltip (red on black)
Regarding the "unsure" findings:
Most issues with icons in high contrast modes (of Windows 10) should have been fixed. Needs to be verified especially with the high contrast modes of Windows 11.
Setting to Testing.
Yes, for GPD and VSD there probably should be version numbers in swdb.lst if the update check should actually be active in those distributions. I think for VSD the update check is usually deactivated because a) it accesses the public internet which some customers don't want and b) the software is usually not installed by the users themselves so that the update check doesn't make much sense.
So, what shall we do with vanilla kleopatra, or GPD or VSD? It will be easy to record current versions number in swdb.lst
Tagging with Windows because the update check is a NOP except on Windows.
looks good to me on gpg4win-5.0.0-beta190@win10
on gpg4win-5.0.0-beta190@win10 (high contrast):
I found more issues with the success, warning, and error icons we show in various places.
looks good to me on gpg4win-5.0.0-beta167@win10
For reference the related MRs for upstream:
https://invent.kde.org/plasma/breeze/-/merge_requests/540 (pending)
This might also be related to rGa7ec3792c5 (cf. T2982)
Fixed. If high-contrast is active then tool tips now use the same colors as buttons (e.g. white text on black for Kontrast No. 1).
With the above patch for breeze the toolbar and the configuration dialog title now also look correct in high-contrast mode.
The wrong/inconsistent coloring of the icons has been fixed.
kleopatrarc, kleopatrastaterc, klanguageoverriderc, libkleopatrarc, and kxmlgui5/kleopatra/kleopatra.rc are now copied from the old location used by Gpg4win 4.4/VSD 3.3 (%APPDATA%/kleopatra) to the new location used by Gpg4win 5 (%GNUPGHOME%/kleopatra) if they do not yet exist at the new location. This is also logged.
The migration of the group config file works again.
Right when you use a different homedir you also need to pass --homedir to gpgconf or set GNUPGHOME before invoking gpgconf. If you call gpgconf via GPGME the --homedir option is passed; afaics we don't have a kill option gpgme.
Released with libassuan 3.0.2 (T7163)
This issue occurs when using GPGME with multiple contexts and setting the OpenPGP engines to different GnuPG home paths. As you mentioned, it is crucial to let gpgconf know the correct home path so that it can locate the socket file used by gpg-agent and properly clean up all instances.
gpgconf assumes that there is only one of the daemons. In fact it can only work with one and that is the one daemon which listens on the socket. all daemon's do a self-check by trying to connect to themself and terminate if they realize that they are not anymore the owner of the socket. As long as a daemon is started by a gnupg component a file system lock is taken to avoid duplicate launching. However it a daemon is stared by other means this could lead to a race.
Maybe the title should be "Password - Kleopatra" (or similar) if the operation was triggered by Kleopatra.
Since codesigning for all dlls was added this is fully resolved.
Here is a patch to support "w32_error" for assuan_sock_get_flag function.
I can say it's fixed in 2.4.7.
In select_application function, we can minimize the holding W-lock.
This may requires major changes for scdaemon.
For the cancelling operation, each card reader access should have an independent resource manager context.
Currently, a single pcsc.context is shared by all reader accesses.
Hard lockup should be avoided. In particular, following conditions should meet:
As of 2024-11-18, my hypothesis is:
@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.
I put "scd" tag and let me claim this ticket.
The symptom of this bug was:
After I fixed the problem, I realized that the description of this ticket was not accurate, so, modified.
gpg4win 4 has been released with unicode support. Closing.
with gpg4win-Beta-50: "Rückstellcode" is shown correctly with an ü
This works now.
Well for 3.3 we will have full support for high contrast with the correct icons on all platforms, additionally we detect and support dark mode on all Windows 10 Versions > 1709 So this can be resolved. (Both for Qt5 and 6). What I have not yet checked if Qt6::systemInfo::colorScheme reports the correct one under windows 11 desert theme, but as you mention that is also part of a different issue where when then also should clean up the kleo systeminfo etc. if this is reliably supplied as information by qt.
Setting this to testing. Could be tested as described in https://dev.gnupg.org/T7188#188093 by verifying that the logged debug messages also use correct encoding.
Okay. Done in gpgme for gpgrt >= 1.51 (T7188).
Sounds like a good idea.
@werner Would it be okay to call gettext_use_utf8 (3) in gpgme's do_subsystem_inits where we currently call gettext_use_utf8 (1)? See https://dev.gnupg.org/source/gpgme/browse/master/src/version.c$77