This was fixed.

No... In this situation, my atachment is a rar file

Interesting. Thanks for reporting this. This happened in the past because images had a "content-id" (so they were marked to be an embedded image) but were not really embedded. I did not have a very good fix then because it is hard for us to detect (easy for Outlook itself though) so there might be more special cases where this happens.

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.

But to resolve this bug I also want to remove stuff like "ooooh you should use numbers or something like that" we have that in configuration but our default code is too dumb to be useful (afaik "password" is accepted with 90% quality). We also have a bug for the quality thingy, which I also find important because that is the first contact with our software.

Found it: T3724

No that bug is different. Nowadays you have to solve four dialogs to create a key without a passphrase.

So you mean the bug that you see a second set of passphrase dialogs iff you told the first one that you don't want a passphrase? That is not trivial to fix because we use the passphrase cache to avoid the double passpharse questions. Without passphrase cache we need a separate code path.

No! That is not what I want with this issue. We should ask once for a passphrase and then shut up.

Yeah, it is annoying. Maybe it is indeed better not to ask for a passphrase at all.

I know, I helped implementing that. Patrick changed it.

Enigmail used to use gpg-wks-client. @kai implemented it back then and we had a milestone meeting to show that it works with posteo.

I want to have this fixed for the next release so prio high.

Oops. Assignee removal was an accident. Sorry for the noise here ;-)

Just as a note: To workaround this you can also place "no-use-tor" into %APPDATA%\gnupg\dirmngr.conf (you might need to create that file) %APPDATA% expands to something like "c:\users\yourname\appdata\roaming"

In T3381#121973, @madhon wrote:

In T3381#121972, @Spiker wrote:

On Win 10 Pro it looks like File Transfer Server.exe is running on port 9050 which could be causing the issue. See screenshots.

That process is the one i killed which is part of Asus Wi-Fi Go

In T3381#121972, @Spiker wrote:

On Win 10 Pro it looks like File Transfer Server.exe is running on port 9050 which could be causing the issue. See screenshots.

On Win 10 Pro it looks like File Transfer Server.exe is running on port 9050 which could be causing the issue. See screenshots.

Apparently i had a ASUS Wi-Fi go process listening on that port (even though i thought had uninstalled it), killing the process also allows dirmngr to start

Thanks you very much for your help! I think we have it. \o/

Running with the --no-use-tor results in output ending with OK Dirmngr 2.2.11 at your service, attached is the procmon output , to clear up one thing q4master.idsoftware.com points to 127.0.0.1 in my hosts file (in addition to localhost also pointing to 127.0.0.1), but it seems the issue is with the tor check

I see some strangeness:
A TCP Connect: q4master.idsoftware.com:4862 -> q4master.idsoftware.com:9050
and TCP Send: q4master.idsoftware.com:4862 -> q4master.idsoftware.com:9050

Sorry for the mistake!
It seems related to the load of the cpu. I'm using win7 32 bit in a netbook. When cpu is heavy loaded corruption is worse. I don't know if it's really relevant, only seems!

I think that this is the name of the integration tool with the desktop, isn't it?

Using gpgme means selecting the folder and use secondary button of the mouse (I think that this is the name of the integration tool with the desktop, isn't it?). Also fails using Kleopatra menu.
I tried several times with the same folder and I obtained diferent results. If I zip the folder and encrypt a unique large file seems to work fine. It seems to fail in pack-encrypt phase. Decoding several times the same encrypted file gives the same wrong result. Decrypt using command line also gives a wrong result. I didn't try to encrypt-tar from command line.

Done, See attached

I was able to reproduce this. I tried it three times with a very large folder and it worked fine. The fourth try though created a corrupted archive and Kleopatra did not show an error either creating or extracting this archive!

Thanks for the confirmation and additional info. In that case I give this high priority as I agree with the potential for data loss.

I'm thinking of how to move this forward.
The problem is that we (the developers) can't reproduce this at all and the debug output does not show anything.

No, thks. It's just a test to confirm this rare behaviour. I did the same test several times with several and diferent results. But I think that a data corruption occurs sometimes when encripting a folder with several and large files. Just aconfirmation of the bug for the developpers.

Hi jmrexach,

Hi, jmanuel, I agree with you.

I almost forget. If I zip the directory and the encypher the .zip file through Kleopatra, everything goes ok.

Have you used a very old version (< 3 ) to create the directory? I know you said that you are currently using Gpg4win-3.1.5 but maybe you have used an older version to create the archive.

The cyphered directory is a Windows 10 directory.

Have you used a very old version (< 3 ) to create the directory? I know you said that you are currently using Gpg4win-3.1.5 but maybe you have used an older version to create the archive.
In the past we had a problem that Kleopatra would not see the errors from the archive program but that was fixed some time ago. The Archive problem had problems with non ASCII filenames but nowadays it only has problems with full unicode filenames and those errors are shown in Kleopatra.

Hi,
we have a rare situation where the Home directory of Kleopatras backend ( gnupg ) becomes corrupted. This results in undefined behavior and strange error states from which we do not yet recover.

I don't think the cause of the corruptions is user interference. Users which report that don't even know about the GnuPG home directory in advance. I think we have some kind of rare bug which causes the keyring to break.

Hello, I'm trying to create my key with Cleopatra. It does not work.
At first it looks like it will work. The normal dialogue comes:
F576314: 1.jpg
The following when saving a backup, the following error occurs:
F576316: 2.jpg
When updating the certificates comes the following dialog:
F576319: 3.jpg
Enclosed the log files:
F576313: kleopatra.log.8456
F576312: Cleo-log
F576311: kleopatra.log.7084
Looking forward to help. Many Thanks

Since today, I cannot send any Signed email. Outlook is crashing.
I guess it is due to the new version of GpgOL I installed.

You can save as text or html decrypted. And apart save the attachment. You can save as .msg in encrypted form dragging and dropping the message row to the desktop. In Outlook smime native mode you can save as .msg in encrypted mode (could be the key cache decrypts "on the fly"). This option seems disabled in gpgol.

I can reproduce it. For me the image is properly attached, I can access the file, but the embedded image does not work. This will be because the content_id is mixed up. I don't know why this happens yet.

I've opened T4322 for the image embedding issue.

In T4318#121604, @che wrote:

Ok, so saving a decrypted message is not possible at the moment, right?

Thanks to the remediation.

Hi Andre,

I think I understand what is going on here:

@aheinecke the file is gpgolXXX.dat. I never got the winmail.dat (I think).

Thanks for taking care of the action.

@MThib What is the filename of the .dat with the original message, is it gpgolXXX.dat or winmail.dat and can you confirm that even without an attachment any modifications to the forwared mail are ignored and the mail is sent out as if it was send again?

There appears to be something very fishy when forwarding from the sent mails folder. Even without attachments if I forward and modify the content the original message is sent out and not the modified one.

Thanks for reply and clarification, regards danny

It is a bit related to T4241 indeed. As we have not yet seen a way to determine if the user actually triggered "save as" or if outlook just wants to save the modifications we can't decide when we should pass the save event and when we should block it.

Thank you for the report. Sadly this is a long standing bug that is still not fixed. We hope to address this in a future version.

Thank you for your detailed report. I agree that this can have serious consequences as it might send out unintended information. I'll look into it with high priority.

Indeed in view of this data, it seems to be that the problem occurs by Microsoft. It fits also with the fact, that all other signatures are working fine from my experience.

I agree. It seems a MS trouble. It remembers the trouble that you have when send email of new version available for your software. Something modifies the signed content.

@jmrexach Thanks for the reminder, I confused those with other mails I've gotten regarding this issue.

Andre,
Were useful for you the files that I sent yesterday? There were extracted using MFCMAPI MFCMAPI tool once emails were collected but before opened by Outlook. When it's checked one of them fails to verify signature. Other two are ok (diferent origin but the same key).

@JW-D I would very much like to but I still only get an error on that page. Can you give me another, working, subscribe link? Maybe I found a wrong one.

A pristine file I do not have, because every file passes GpgOL before displayed. I suggest, you subscribe to the service and if you de-install GpgOL, you should obtain a pristine file.

3.1.6 will have two ways to install the browser integration non-interactively

Ok. So the tooltip was another issue. Which I've fixed now.

No, I can´t confirm it, I get no reason displayed. The key which I use is shown in my screenshot (I´ll send by e-mail)

The tooltip:

I must make a correction of my earlier statement from today. The three Microsoft messages were not displayed in the same order on the screen on both machines. I must say, that on Outlook 2016 AND Thunderbird PGP verification still fails by "Microsoft Security Update Releases". It is the same situation as last year, nothing has been changed. I sent two files in EML format and some screenshots to A.Heinecke today.

I'll work on this right now. Please wait with contacting MSRC before I have a chance to find out what the problem is.

Yesterday Microsoft issued three PGP signed mails. It is the first communication after MSRC confirmed failure of verification and promised to have internal procedures changed. I received those mails on two different machines, one equipped with Outlook 2016, the other with Thunderbird. Last year all messages failed on Outlook and Thunderbird, if the were issued from "Microsoft Security Update Releases".

Should be looked at before the next release.