Code for avoiding the COMMON section has been there, because of RISC OS.
I think that it will be easier to enable that for all (but not for RISC OS only).

It is quite likeley that things don't work on a non-released Windows version. We have not tested with the released version but some of us already tried Windows-11 and the gog4win development versions do work. Please wait for the next Gpg4win version or an update of the Windows-11 preview.

Im using Windows 11
Before the restore, he are working fine
Im trying to sign a file
The kleopatra dont show more error info

Package maintainer from PLD here. We still ship Qt4 and therefore provide pinentry qt4 for as long as it's supported. I have no problem with dropping it if it's no longer support, but last release still supported Qt4, there's no mention of dropping such support in NEWS and both code as well as configure.ac appear to still carry Qt4 support which is a bit confusing.

Qt4 is no longer supported. Please use the previous released version plus commit rP2859eddfb0c9: qt: Fix build against Qt4 to build pinentry for Qt4. For everything else use 1.2.0.

Will only be fixed for 2.3 and that has already been released.

I tried applied the bulk of the patch to 2.2 but w/o reading the key creation time from the card. We don't have the supporting code for latter in 2.2. However this does not make sense. Users should switch to 2.3 if they needs this feature.

I have rather created D536 as IMO the timeout should be changed, not the documentation.

We need a more detailed bug report to evaluate your problem. Please tell us your Windows version, any special software installed on the system (if any), a step by step description how to reproduce the bug, and any other information which can help us.

Thanks fro the report. Unfortunately I am not able to reproduce this on our systems. It might be an issue with other software on your system or a problem in our code. This is the first such report and as long as we don't get reports from other users, we can't do much for you. Please try installing on a different system or if you can provide more information feel free to re-open this bug report.

Will do.

To fix this, rG48251cf9a7d3: gpg: Improve generation of keys stored on card (brainpool,cv25519). for GnuPG 2.3 should be backported.

Fixed in libgcrypt 1.9.4.

Fixed in 2.3.2.

It must be fixed in 2.3.2. If not, please report.

Oh yes, I was blind.

Here is the place:
https://dev.gnupg.org/source/gnupg/browse/master/g10/pubkey-enc.c$151

A cursory look doesn't show me where list->result is set to something else than -1. Can you give me a hint?

In GnuPG 2.3, the procedure of decryption has been changed;
It now collects all ENC_TO packet, keeping it to ->PKENC_LIST field, and then process ENCRYPTED packet with the list.

So it is related to code page. Screenshots may be more informative:

After several days of observation, after modifying the configuration file options , the problem has indeed been greatly alleviated.

Fallout from the fact that the @cbiedl left us and had an internal non-tagged ticket left open (T5456)

I see whats going on. The GitHub gpgme mirror (https://github.com/gpg/gpgme) is no longer updated. The last commit is from June 22, 2021. Changing the source link to the official (https://dev.gnupg.org/source/gpgme) URL gets the latest updates, and now builds successfully.

This has already been fixed with rM4b64774b6d13ffa4f59dddf947a97d61bcfa2f2e

Frankly, I don fully understand your report. Can you please clarify?
Note that with 2.2.8 we introduced full Unicode support on the command line. If you see scrambled output you may want to "chcp 65001" to get the output correctly rendered.

I have recently been busy with the new features and mechanisms of the GpgFrontend project.

In T5436#148656, @cnp1234 wrote:

I added "disable-application piv" to ~/.gnupg/scdaemon.conf and the behavior went back to pin caching working as before. Since I don't use PIV, this is an acceptable workaround for me.

I added some asserts. However I doubt that it can be hit by LibKSBA. I also fixed a real bug related to VALTYPE_BOOL - but that is also not used in Libksba.

For tests with FIPS mode enabled, I manually create the file .libgcrypt.so.20.hmac under src/.libs.

I pushed my further change.
Also, applied and pushed your changes.

Sorry, I didn't test for non-FIPS mode when I committed rC347817438990: fips: Fix tests in fips mode..
Tweaking the value for memory allocation is needed for FIPS mode, because it uses some secure memory by DRBG.

Tested the master on (faked) FIPS and non-FIPS Fedora and I created couple of more changes for master to work in FIPS mode:

keyserver hkps://hkps.pool.sks-keyservers.net:80 is problematic.

Did you restart dirmngr? ("gpgconf --kill dirmngr" so it will be started on demand).

debug network,dns,ipc
log-file C:\Users\Administrator\dirmgr.log

I wrote this in my dirmngr.conf. But i haven't found this .log file.

Based on the info about this being caused by the added support of PIV, I poked around on the docs at https://gnupg.org/documentation/manuals/gnupg/gpg_002dcard.html and noticed the disable-application stuff. I added "disable-application piv" to ~/.gnupg/scdaemon.conf and the behavior went back to pin caching working as before. Since I don't use PIV, this is an acceptable workaround for me.

debug network,dns,ipc

log-file something

I can confirm that Kleopatra seems to use the system's locale and not the system language, using English language with Dutch locales myself. The language selection dialog shows the correct languages (en_GB as primary and en_US as fallback) but the interface is Dutch.
Kleopatra 3.1.16 on Windows 10 21H1

Yes, I infer that the problem lies in the network-related modules. Because this waiting time is too long, it is probably not a problem of calculation and disk.

Which reminds me that we should add a cronjob feature to dirmngr (which already does some background tasks) so that we can easiliy make use of --no-auto-check-trustdb on Windows.

This could be caused by the periodic automatic update of the Web of Trust information. See --auto-check-trustdb in man gpg.

Let me try, this problem sometimes happens, so it may takes some time to come to a conclusion.
But what I know is that after experiencing slow loading, it will not appear again when it is opened again later.

Is there any change if you enable the keyboxd to store the keys? Put

I tried a fresh card reconfigured it to use 3 4k RSA keys:

This has been fixed with rP9dd46926f8d5: qt: Fix showing of pinentry window on Wayland.

Thank you! But let me mention, that my older smart cards (Version 2,2) holding also RSA-4096 keys. They could be generated on card without any problem. I had the problem only with OpenPGP cards version 3,4. This I would like to strenghten.

Thank you for the information.

My setting is RSA-4096 key. Also it showed "pipe was broken", but it disappeared too quickly, so I do not have a screenshot from that.

I checked with my OpenPGP card v3.4.
It works for me with GnuPG 2.2.x and 2.3.x.
My setting is for RSA-2048 key.

Hmm, do we need a backport?

Hi, I have the same problem, in Italian Language becouse this is the system language!
Kleopatra 3.1.16 on Windows 10

Can confirm this problem still exists in version 3.1.16. The context menu in Windows Explorer and some menu entries in Kleopatra are in the wrong language, while most of the application is in the correct language. This looks very messy.
Gpg4win and Kleopatra should not look at the date/format locale settings for the language, but at the actual Windows display language.

As a start, I applied your patches.

dlopen'ing of gpgme is NOT SUPPORTED. It is in general not a good idea to do this on standard Unix systems.

To extend on this: dlopen'ing of gpgme is NOT SUPPORTED. It is in general not a good idea to do this on standard Unix systems. On Windows we could make it work because DLLs on that platform are well designed and not a hack like the Unix shared objects.

We really want thunderbird users that interact with GPGME to have a great and stable user experience, but the problem with dynamic loading and self compiled versions is that we cannot really know the build settings and enviornment and it is very time consuming to reproduce that. GPGME does some very low level things for optimized IPC that can depend on build options etc. This is why I am mostly in favor that thunderbird ships a defined version that we can debug and see the settings.

Reading the mozilla entry more carefully, there still seems to be an issue.

https://blog.gerv.net/2012/01/mozilla-projects-and-gpled-code/

@kaie, thanks for the pointer!