Thanks Andre for your response..

I am pretty sure that we can fix that issue and have a beta for you maybe even today or tomorrow. But afterwards we should talk about your company actually using a product with professional support (which you are getting right now from me) like GnuPG Desktop. Gpg4win is basically only "goodwill" support.

andre said this can not be left like this, on windows the name needs to be "Archive (1).tar.gpg", like in Linux.

See also T4365 and rGb912f07cdf (gnupg-2.2)

gpgconf --show-codepages ist just a debugging aid. We use the code pages only for output to the console. The problem we see here is about log messages and they are always send as utf8 to stderr or the pipe used instead - without any translation.

In the VSD Testversion:

As far as I can tell and see with my limited tests, everything works (for me). There's nothing else I can do and I don't have the slightest clue why it seems to fail sometimes. Somebody else needs to take over.

With regard to invalid characters in error messages as in T5960#172860:
We are using the identical function everywhere to convert the error codes to text. If an invalid character is displayed if copying a key to a smart card failed, then invalid characters should also be displayed for example if one tries to decrypt something in the notepad without having the necessary secret key. I get "Kein geheimer Schlüssel" in this case, i.e. no invalid character.

The remaining problem with output that's read directly from a GnuPG process seems to be that sometimes gpgconf --show-codepages prints 0 as ConsoleOutputCodePage or even as ACP (as in T5960#175580).

I tried to reproduce this with a locally built gpg4win-4.2.1-beta56. Using localhost as keyserver I got (after a looooooong timeout)

This did not fix the issue on Windows.

Hi Dan,

I tested once more with another person, issue confirmed, he can read my encrypted mail (as you did), however, I can NOT read his emails (with the same error: you cannot be sure who encrypted this message as it is not signed)

works

Yes the error message is better now. In German it is "Entschlüsseln fehlgeschlagen: Fehlerhafte Daten." Which could be a bit more clear, but its ok

Yes, I can decrypt my sent mails, in my Sent folder

well yes, it ends now in "_signiert.pdf" with German language settings and "_signed.pdf" in English.

To say this differently, the problem fixed recently which Relaxed detection of encrypted mails might still fix your problem. But the "corruption" of the mail which makes it harder to detect as a crypto mail for GpgOL does not happen when you send a mail, it appears to happen when you receive a mail.

Received, but it is not the same problem at least on your side. Your mail looks perfect. It would have been handled by any version of GpgOL on my side. So I think it is the receiving side meaning your incoming crypto mails are modfied by some middleware in a way that GpgOL does not detect them as crypto mails anymore. But before we debug more here with logs for you, let me finish up some other work on GpgOL and I can probably give you and some others in the tracker here a beta this week where we can then confirm if its already fixed. I'm currently actively working on GpgOL.

I sent the test encrypted email

Thanks once more... and appreciate your swift response.

Yes the resolution in that issue is "I have fixed this, you need to wait for the next update." The comments above explain the problem, the mail is modified in transit, if you change something there then you can maybe workaround in the meantime. The exact comment I linked gave the instructions on how to assist with analyizing this issue. If you would follow them I could also tell you for sure weather or not this is your problem. https://dev.gnupg.org/T6686#174856

ok, with the new testversion VS-Desktop-3.2.0.0-beta214 and without Debug redirection (mea culpa), the info window looks like this:

Thank you for your reply.

This sounds a bit more like you would maybe better suited with a batch script or command line usage anyway if you always want to encrypt in the same way you don't really need a fancy GUI for that.

Ok. Let me unpack this for you. I think your problem is that now since you switched to your new domain the mails in Outlook are no longer directly decrypted, then you open the attachment and get this message.

I am closing this, for now as this issue lacks actionable details, we would need an example mail or debug data. So my intent is just to close it and reopen if the issue still occurs with Gpg4win-4.2.1

Noticed this issue while searching for a different one.
I think this could be fixed with T6686 if it has not already been fixed by a previous change that relaxed the detection of the encrypted message part better.

Why do you think that no WKD lookup occurs for keys of unknown origin? gpg and therefore Kleopatra doesn't report any import results for certificates that are not published via WKD when doing --locate-external-keys --auto-key-locate clear,wkd.

Hi, it would be great to make Kleopatra remember the last used settings.

Thank you for your time and your answer, we really do appreciate your work. We invested in this in hope to help make the software better. Please try it, so you will see how it works. We were able to reproduce the problem the way I described. When installed as a normal user it won't work. Installed as an Administrator user it works. So the more secure way does not work currently.

The way how you install it can have nothing to do with that, it must be a different issue, but it sounds to me like you are messing with privileges a bit too much. Did you ever receive the warning of Kleopatra that you are running it as Administrator and that will mess up the rights in your GnuPG folder? Be honest. :)

You mean if you right click on a file and select sign & encrypt or if you choose the action from Kleopatra?

For another user this change caused endless syncs. Since I do not yet see a way to fix this without risking again that the plaintext leaks to the server under some circumstances, because the problem is that I still do not know how to reproduce these circumstances, my plan is to at least add an option in the debug tab of Kleopatra to disable this "save back" feature.