3.1.6 is released.

3.1.6 is released. Please test again and reopen this issue if you still have problems.
Thanks!

3.1.6 is released.

3.1.6 is released.

3.1.6 is released.

3.1.6 is released.

gpg4win 3.1.6 is released which contains this fix.

3.1.6 is released please use that one.

3.1.6 is released

This has been implemented.

I've started some documentation how to repair a broken archive under: https://wiki.gnupg.org/TroubleShooting#Restoring_corrupted_Archives_created_by_Kleopatra

Doesn't look like T4347 in that no errors show
stopping daemons and restarting kleoptra "sometimes" fixes it and pinentry windows shows, until it does all operations fail with pinentry missing
running pinentry-qt.exe I get
Please note that you don't have secure memory on this system
OK Pleased to meet you
We seem to have stopped it happening by randomly changing settings - generating blank conf files, reinstalling pgp4win but cannot pinpoint exactly what change fixes the error and because it's intermittent we may just be getting lucky

If the filename embedded in the encrypted message differs from the filename Kleopatra uses (which is derived from the file system filename) Kleopatra will now show the filename. This should cover the case where users receive an "Attachment.pgp" and do not know what that is.

Could it be that you are running into: T4347 ? Maybe this will just be fixed for you then in the next version.

@nbriggs No this is not related if you get "no pinentry" it means pinentry is not started at all. This issue is about pinentry starting but not properly coming to the foreground. I've opened T4430 for your issue.

Hi,
I'm pretty sure that I finally understood it and fixed it. There was a data mismatch between the IMAPISecureMessage and IMAPIMessage which somehow only happened for sent mails. This case is now handled.

There was indeed a problem. With a test card I could reproduce the issue and fix it.

in I think a related scenario we are having the pinentry window not spawn at all, leading to "no pinentry" errors
Win 10 latest patches Mar 2019
Version 3.1.4-gpg4win-3.1.5
We've tried a few hacks including adding the .conf file to C:\Program Files (x86)\GnuPG\bin with
pinentry-program "C:\Program Files (x86)\Gpg4win\bin\pinentry-qt.exe"

It may be our McAfee, that’s the usual culprit when something is being blocked that we need. Thank you for your help, I’ll let you know if this works for us!

[Randall_Meredith_ESig_7.14.17]

From: aheinecke (Andre Heinecke) [mailto:noreply@dev.gnupg.org]
Sent: Monday, March 25, 2019 2:36 AM
To: Randall, Meredith <MRandall@hoosierlottery.in.gov>
Subject: [Task] [Triaged] T4419: GPG4win not installing on Windows 10 Laptops

• This is an EXTERNAL email. Exercise caution. DO NOT open attachments or click links from unknown senders or unexpected email. ****

aheinecke triaged this task as "Normal" priority.
aheinecke added a comment.

The step where it is hanging at is to register the GpgOL Addin with Windows.

Can you try the hanging command on an elevated command line maybe without the /s switch which is for "silent"

c:\windows\system32\regsvr32.exe "c:\program files (x86)\Gpg4win\bin_64\gpgol.dll

Maybe it gives an error or shows some more information. Alternatively maybe a security software jumps in there and blocks access to loading this dll. Any unusual security software installed?

TASK DETAIL
https://dev.gnupg.org/T4419

EMAIL PREFERENCES
https://dev.gnupg.org/settings/panel/emailpreferences/

To: aheinecke

Cc: aheinecke, mrandall, Rafixmod, ccharabaruk, gp_ast

This is an automated email from the GnuPG development hub. If you have registered in the past at https://bugs.gnupg.org/ your account was migrated automatically. You can visit https://dev.gnupg.org/ to set a new password and update your email preferences.

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.

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.

I've recently moved from the Windows 7 system where I saw the problem to a Windows 10 system where Kleopatra works. As Windows 7 will no longer be supported by Microsoft, there seems little point in working on this issue, so I'd be happy if it was closed as Won't Fix.

Great. Let me know when the newest gpg4win is released.

Hi - that did the trick. The linked gpgol.dll loads without any issues. However the decryption of e-Mails don't work. I get the
"OpenPGP Encrypted message (decryption not possible) Could not decrypt the data: Unsupported protocol" error.

Great. Thank you.

Thanks for the confirmation. Although I still don't really know how to fix it :-(

We are aiming for this week.

When will the new gnupg program be released so I can install it?

Charles

I can also confirm this bug!

So where can I get the corrected file to install? I suppose I need the
new gpg4win, it hasn't been updated yet. If I need the signature or TAR
from your website how can I implement that?

Charles

see: https://wiki.gnupg.org/TroubleShooting#Manually_update_GpgOL_to_a_beta

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.

Where can I get the new thing file to install?

Thanks! I've confirmed that it works for me.

Since I configured call tracing the running O365 Client dies immediately after activating the addin. Same happens now if I activate the addin.
Anyways, here is the log.

Thanks for the report. Log looks not unusual.

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.

The secret import code actually had a bug in that it silently imported the secret key anyway, so that after importing the public key the secret key showed up. That was not intended because we do not want to allow importing arbitrary keys or subkeys if the don't have a corresponding public (sub)key with the mandatory key-binding signature. This has now been fixed. A fix for the actual problem will come soon.

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.

The issue for the quality indication is: T2103

FWIW I like @gouttegd 's patchset.

In T4346#122098, @werner wrote:

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.

Ok. Let me know so I can try it out.

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.

Checking the OpenPGP specs again, there is actually an "exit" clause for this PGP bug. Or well, what I would consider to be a bug. A fix for this is not easy because it would require to detect this at an outer level (the ascii armor) which we don't do because gpg is build along a streaming concept as almost all Unix tools. What we can do is to allow import of a secret key in that PGP format iff a public key is already there. In practise this would mean to run the import two times and ignore the errors from the first import.

Do you think you can do it with a new gnupg?

Charles

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