I'm changing this to testing as the original problem is now fixed with a good solution that properly detects the contents of ms-tnef wrapped messages.
Frustrated my self by not getting out the release.
- Added proper "ms-tnef wrapper" handling in GpgOL (T4403)
- Worked on getting diagnostic output of GpgSM through GPGME.
- Did some release testing while waiting for a debug log on friday.
- Some smaller fixes for Kleopatra and GpgOL.
b8d651c4d083d2295cdd75e9f5882ab36ef8f418 Fixes this issue.
Can you open the command line (cmd.exe) and execute there: "gpg --passwd 6B05B09F" ?
The step where it is hanging at is to register the GpgOL Addin with Windows.
Wed, Mar 20
Thanks for the confirmation. Although I still don't really know how to fix it :-(
We are aiming for this week.
Tue, Mar 19
@dkg If you propose a patch here I'm pretty sure that we will accept it. As one of our Python binding users you know better then us how the API should behave.
This is very strange, common to all the crashes in the log is that they happen while a keylisting is running and before the first key from that keylisting is returned. But this could be a red herring because the keylisting is always started immediately in a background thread and so it would be normal that if the crash occurs immediately that it would still be running. The keylisting code is extremely similar to Kleopatra though. So I don't understand why Kleopatra would then work for you.
Thanks! I've confirmed that it works for me.
Mon, Mar 18
Thanks for the report. Log looks not unusual.
I think that this might have the same underlying reason as the fixed T4321 (still open because it was not yet released).
- Lots of debugging and code staring for T4332 It looked very much like QProcess issues on Windows. It is fixed now by using our own "CreateProcess". This was the last "Release blocker".
- For GpgOL I've debugged an issue with exchange <> exchange S/MIME messages.
- Some packaging work for scute
- Fixed a dependency tracking issue in Gpg4win
- Fixed an issue in GpgOL that categories were sometimes not added correctly. (It uses localized seperators for categories,...)
Just for history if I ever need it again here is a patch I wrote debugging QIODeviceDataprovider. I have not commited it for fear of regressions and apparently the code is correct for Linux and that it did not work as expected on Windows had other reasons.
Fri, Mar 15
After further debugging it showed that it had to be an issue in how we use QProcess. So I've rewritten the way we call gpgtar on Windows and replaced it with a simple anonymous pipe solution. I've tested more then ten times with various directories that the data corruption no longer occurs.
The performance is slightly better, but we still use GPGME so it's not as good as if we would pipe it directly. But not using GPGME was not really an option because otherwise I would have had to implement a full blown "how to call gpg" with error handling etc. for Kleopatra and I really did not want that.
Thu, Mar 14
The issue for the quality indication is: T2103
Regarding the quality evaluation, several months ago I proposed to optionally delegate that task to an external tool (specified by a new gpg-agent option passphrase-checker). I posted a first draft as D442 and then submitted a proper patchset to gnupg-devel, but although @werner expressed interest it was never merged. I have just checked that the patchset still applies cleanly to both the master branch and the STABLE-BRANCH-2-2. I can re-submit it to the mailing list if needed.
FWIW I like @gouttegd 's patchset.
The quality bar is switched off by default. That feature including the quality was ordered and accepted by a client. I don't like it either and thus the new default of having it disabled is a useful solution.
Wed, Mar 13
thanks for the report. Yes this is a known issue. This pinentry is so basic that it does not have dynamic layout as we don't include GUI libraries in the basic installer. For a better pinentry you can install Gpg4win.
In the future we are thinking about adding a pinentry based on the small "FLTK" toolkit, with dynamic layout.
Tue, Mar 12
Yes, I think that if I see an import result with "secret-keys-read && w/o userId's" I can just do a second try.
Mon, Mar 11
By the way. As I see the domain in the screenshot ;-) let me just say that there is commercial support for GnuPG (https://gnupg.com) available and through which we could much better and quicker help you to find a solution that works for you if this is a problem in your organisation.
It's better to have a new Task for this as I explain in T4402
I think I know what the problem is. T4038 only works for "legacy algorithms" this means old ciphers where MDC was not the default are handled by this error. New algorithms like AES which should have MDC in all implementations were not affected by this because this is much rarer and points to a broken implementation / a real attack.
%APPDATA%\gnupg is a windows variable which expands to something like:
This can happen e.g. if there is a permission problem in the GNUPG home directory (%APPDATA%\gnupg) e.g. if the file S.Uiserver in there was created once with admin permissions it can not be removed or reused by a kleopatra running as a normal user.
Thu, Mar 7
Oh my,.. I tested it myself with the very latest PGP Desktop version and this is really what you get as output.
I'm not sure yet where the bug lives. It's either in GPGME's editkeyinteractor that ignores the error / cancel or in Kleopatra itself. I'll have to look into it. Btw. I do not think that this should have high priority because it is not a new regression and while it is a Bug and wrong it is not really harmful.
I've opened T4395 for this to keep better track of it as this task was about another issue.
From a comment in T3990