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

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:

• gpgconf --kill scdaemon can kill scdaemon
• KEYINFO requests can be answered for other connections of scdaemon

As of 2024-11-18, my hypothesis is:

• there are some sort of race conditions between PC/SC + card reader (or its driver) + smartcard + scdaemon on Windows, at least at initial use after boot
• because of this, SCardConnect of PC/SC call wrongly fails (somehow confirmed by @ebo's experiments + @gniibe's speculation), or wrongly never returns (@gniibe's guess, side info: its slowness is observed in T7400).

@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:

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

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

Alright: Call gettext_use_utf8 (3) to set the current thread to utf8 and init all new threads to utf8 as well. This function with that value (actually bit 1 is relevant) can be used several times but it will never switch back the initialization to utf8. However, switching back and force to utf8 per threads is still possible.

KWin has a script called "Dim screen for Administrator Mode" which mimics the windows behavior.

This should be tested as part of testing T5960 by checking that the German error description "Falscher Rückstellcode" is shown after entering a wrong reset code (PUK) for an OpenPGP smart card (https://dev.gnupg.org/T5960#188013).

Using/setting a value of 2 would work for Kleopatra.

That is probably right for gpgme as used by kleopatra. However in gnupg we need to switch utf8 on and off.

This also works for VSD 3.3 (because the required changes/patches are in gpg4win).

For the white high-contrast mode we use the normal (black) Breeze icons now. I think for Qt 5 that's all we can do with reasonable effort. For Qt 6/KF6 we have to revisit this anyway because a lot has changed (see T6932).

In T7175#187690, @jukivili wrote:

Hm, CFI directives should not be used on WIN32 target. This patch should solve the issue for now:

0001-src-hwf-x86-disable-inline-assembly-CFI-directivies-.patch984 BDownload

Using clang for Windows is not tested or suggested. Thus low priority.

Done in 3.0.0.

In future, when spawn function API is used by libassuan (and stable), we can support gpgme with no gpgme-w32-spawn.exe.
(And it will be simpler, just using native functions in libassuan, instead of replacing ones by assuan_system_hooks.)

The official GPG binary from "c:\Program Files (x86)\GnuPG\bin\gpg.exe" does not exhibit this problem. I will report it to the msys2 folks.

Yes, it is the msys2 build of gpg, installed using the standard msys2 methods. The pwd in my example was from msys2 zsh.
I reproduced the error running under msys2 zsh and in Powershell.
If I understand your response correctly, you are saying this will not be fixed in gnupg itself? I can report it to the cygwin/msys2 folks of course, if you think that is best. But I still suspect the root cause is in gnupg, probably in homedir.c or the code that makes an absolute path from a relative one.
I will retest with the official gpg4win and let you know the results.

pwd is not a standard Windows command. It is availabe in powershell but there I get

The reset was due to running gpg-connect-agent reset /bye. I am currently testing something elese will get back as soon as I can turn back to 2.4

There are two locks here; (1) rw_lock for card_top (list of cards) access and (2) individual card lock.
It looks for me that:

• don't know how/what the thread 7208.2 does
• the thread 7208.3: KEYINFO, then PKSIGN (gets read lock for card_top, then, individual card lock)
• the thread 7208.4: SERIALNO --all (and wait for write lock for card_top)

In case if someone finds it through a search:

Removing gpgrt because we meanwhile have full utf-8 support there.

That is an old bug report with a couple of fixes introduced over the years. As of now we sometimes see hangs on Windows on our test VMs. The common cause here seems to be USB card reader issues. Let's close this bug and wait for another bug report with current software versions.

No regression, assuming things work.

All icons that are available in normal/light mode should now also be available in dark mode.

And another note: In KF6 icon inverting happens automatically in ksvg or so, so that we don't need to ship breeze-dark anymore. And there will be a BreezeIcons library including the icons that can be used instead of the RCC file. This means we just need a quick fix for VSD and not a general solution for upstream.

One more data point: breeze-icons installs a copy of all breeze icons that do not exist in breeze-dark in the breeze-dark icons folder. So, with icon files on disk breeze-dark has all icons that breeze has even without using breeze as fallback icon theme. Looks like an oversight that the breeze-dark RCC generated by breeze-icons doesn't include missing breeze icons.

KIconTheme sets the fallback theme name to breeze, but those icons cannot be found because we only load the icon theme RCC for breeze-dark. I think we need to load both RCC files in dark mode. No, that doesn't work.