Hello ...
It is not really helpful if you publish that fact anyway on a public tracker.
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?
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!
It's strange that the problem only occurs locally on one machine. I set up a test bench and did not experience the same errors as before.
Thanks a lot. Due to your log I have tried with a long username and umlauts and a dot in my username. My test name was Längül!ödiföäada.dad which is the longest that Windows allows. But It still works for me. Even if I create one or two gpgol_enc.dat files in %TEMP% It still works:
... Logging active, standard, with email content and meta information
I have produced a log using 4.0.3.
See attached.
strange, I have not received one. Did it bounce somewhere maybe because of size? Encryption should compress this though.
Ok, email sent
Please, Last chance to add a log with Included file names (Include data checkbox) before the next release. Me and a colleague reviewed the function and don't find an issue with it. Otherwise I will only add a MessageBox error in that case for the next release.