With 100 concurrently running gpgsm processes they all try to get the lock for the keyring. And they need to do this several times and often also for the same certificate (fetched from an external resource to complete the chain). Not good. It might be easier to bypass the gpgsm and run gpgsm directly instead of adding a feature to gpgsm to directly import from many files.

Sure, we could do this. Shouldn't make the ImportCertificatesCommand much more complex than it already is.

Reopening this as there still seem to be ways to run into a deadlock as was reported in RT#13361. While I still think this points to some issue in gpgsm, when Testing this I found the behavior of Kleopatra to be wrong.

Has been remedied. We should have noticed before the release but the heavy warnings you get only appear if the binary is downloaded from the internet.

This was an accident. Will be fixed ASAP.

Hello ...

It is not really helpful if you publish that fact anyway on a public tracker.

We sometimes grant our customers the privilege of receiving updates a few days earlier than the community. It is not really helpful if you publish that fact anyway on a public tracker. BTW, there is no community version gpg4win 3.1.26.

works

Fixed by reverting to 2.5.5

The same problem will very likely occur with any file dialog opened by Kleopatra because file dialogs are always modal. It may not be nice that people can maneuver themselves in such a situation, but how likely is it that a normal user (and not just a good test engineer who is looking for such problems) will run into this problem.

Support for multiple smart cards has been vastly improved in the last few years. I will tentatively close this as resolved because it's very likely that the problems have been resolved.

Wild guess: Since creating a local certification seems to work, but creating an exportable certification fails, maybe the problem occurs when trying to promote an existing local certification to an exportable certification.

Closing. Not a bug in pinentry. The user ID of the key is encoded incorrectly and pinentry just displays the incorrectly encoded user ID.

It's irrelevant whether you can trick the combination of gpg and PowerShell to show the wrong encoded user ID correctly. The user ID is still encoded wrongly and every standard-compliant implementation of OpenPGP will show garbage when displaying the user ID.

Interestingly enough if I set LC_LCTYPE environment variable in powershell $env:LC_CTYPE = "C.UTF-8" - it behaves correctly and generates UTF-8 encoded names.

Looking at the hexdump of the user ID in the exported (and dearmored) public key this looks like a classic double-encoding problem, i.e. UTF-8 encoded UTF-8:

42 6A C3 83 C2 B8 72 6E
      ^^^^^^^^^^^

Just found out something weird - powershell tells me the default characterset is iso-8859-1
~~~
PS C:\Users\bbs> [System.Text.Encoding]::Default

okay, installed 2.2.29 and tried showkey:

C:\Users\bbs> gpg.exe --show-key D:\bbs_gpg.public.pgp
pub   rsa4096 2022-11-06 [SC]
      0F20E48DEA9FD7A5626DBA0067BDA85044042E3B
uid                      Bjørn Bouet Smith <bjornsmith@gmail.com>
sub   rsa4096 2022-11-06 [E]

https://gpg4win.org/download.html, but there isn't a Gpg4win release with GnuPG 2.2.29. The most recent Gpg4win 3.x has GnuPG 2.2.28. (All releases of Gpg4win 4.x include GnuPG 2.3.x.)

Yes, seems so. In either case, there's nothing we can do anything about since the versions provided by us appear to work correctly.

But it is strange that the version can show the characters correctly - so it can encode and decode to the same output.

On Linux, I also get garbled output for your key:

$ gpg --show-key <bbs_gpg.public.pgp 
pub   rsa4096/67BDA85044042E3B 2022-11-06 [SC]
      0F20E48DEA9FD7A5626DBA0067BDA85044042E3B
uid                            Bjørn Bouet Smith <bjornsmith@gmail.com>
sub   rsa4096/08D7C29E12A34AD2 2022-11-06 [E]

This indicates that the user ID was encoded incorrectly by the gpg included in git when you created the key.

I am not sure if the export is correct - or if you need something else?

If I import the keys into gpgwin it shows up garbled - both in the console version of gpg.exe and Kleopatra, but if I run

gpg.exe -k

With the old gpg version it shows up as:

/c/Users/bbs/.gnupg/pubring.kbx
-------------------------------
pub   rsa4096 2022-11-06 [SC]
      0F20E48DEA9FD7A5626DBA0067BDA85044042E3B
uid           [ultimate] Bjørn Bouet Smith <bjornsmith@gmail.com>
sub   rsa4096 2022-11-06 [E]

This is the key exported with:

gpg.exe --output D:\bbs_gpg.public.pgp --armor --export bjornsmith@gmail.com

In T6289#165411, @ikloecker wrote:

How did you generate the key? On the command line? Which command line did you use? Can you attach the public key to this report?

It seems like gpgwin generates keys where the name are not compatible with each other.

How did you generate the key? On the command line? Which command line did you use? Can you attach the public key to this report?

Also - gpgwin is no better:

So because I use some thing that "almost everyone does not use" - but something that you distribute you do not even want to fix it?

Actually we have two gpgme versions in gpg4win because gnupg is a "sub"-installer inside of gpg4win and it comes with its own gpgme. That gpgme is the release version but the one used by gpg4win's kleopatra is often a newer snapshot.

great hack

Fixed, to be released with Gpg4win 4.0.5.

I recently noticed that the old workaround by setting a kategory when it is not visible in the messagelist does not work on a default Outlook 2204 anymore. This raises the priority of this issue.

Is that still required wit the new gpgme global flag "inst-type"?

The issue with rWe06c325a9a29 was that it linked in all breeze icons and nowadays would also link in all breeze-dark icons. Which increased the size of Kleopatra so much that there was no performance gain and the fallbacks were still checked. This might require a fix in Qt / Kiconloader not to use fallbacks and also to only resource up the subset of icons which we actually use and package.

In QGPGME which is used by GpgOL and Kleopatra we have solved this by loading the configuration only once and then reusing it. I see no need to change something in gpgconf here.

Hi Werner,

An old version is still installed and the libgpg-error-0.dll could not be replaced. Make sure that you deinstalled old gpg4win versions and other gnupg versions. The file version of the DLL shall be 1.46.x.x.

I tend to close this as a duplicate.

Hidden where?

Added now

inflateGetHeader does not seem to be called by anything from KDE. The only hits are from a copy of zlib included in marble.
https://lxr.kde.org/search?%21v=kf5-qt5&_filestring=&_string=inflateGetHeader

Thanks for mentioning this. I looked at the CVE last Sunday and figured that we are not affected. The vulnerable function inflateGetHeader is not used by GnuPG because we don;'t support the gzip format.

Sorry for the confusion ...
There was no single gpgol-File for deletion.
There were 100.000 other files from other programs.
No idea, why this has interferred with gpgol, but it obviously has.

Ok. So I never assumed that you had actually 100 gpgol_enc_number.dat files lying around.

I had a look into my \AppData\Local\Temp and found some 10,000 Files/Folders (nearly 100,000 files in total) with over 10 GB.
After deleting most of them, GPG4WIN 4.0.3 is working!