Yes and I get the same result with PNG files. But calling shell execute with such an url looks strange to me, I will try QUrl::fromLocalFile as we use in Kleopatra.

Moving the definition and changing it to the name of the po file worked.

Pretty sure its the translation domain. Thanks! Will try to fix that tomorrow

According to werner the gnupg tools use GetCommandLineW even when they are not build with -municode.
So a solution could be to build gpgme-w32-spawn with -municode and start the child process with CreateProcessW, this would also solve the problem that GnuPG could itself be installed into Paths which are not representable in the local 8 bit encoding.

I think that if we know that GnuPG is not encrypting to expired keys we need to use the X icon for that key and disable the sign/encrypt button until this key is removed.

So I think we need to somehow show this. This gives users the option not to encrypt to the one or two expired keys and maybe ask them from updated keys or continue the operation anyway. (Although I am unsure if gpg would not throw an error in that case even with trust model always). From a User Experience standpoint I think we need to make it visible that you had a key for a person once but that this key is expired now. Regardless of wether or not it should then still be used. The "No Key" is a bit of a wrong information here. So show such keys as the first entries and then disable the ok button until the user somehow solves the issue.

Sorting problematic keys to the front make sense to me, but might be complex since we just add the certificatelineedits and then would need to do some kind of dynamic layouting regarding on the return value of the linedits key.

Yes, the wording for this line should be improved, I agree.
In the current release and the releases up to now this action did not work at all when it was not used in combination with encrypt. That usually happens only if an administrator activates the "always_sign" option, prefers S/MIME and then does not issue users with S/MIME certificates. For OpenPGP we have the "Generate" option preselected in that case.

For sent mails folder there is no solution. The problem is that if the mail never leaves the exchange server it is not converted to a standard compliant PGP/MIME but left in Microsofts internal MAPI format where it looks like this. I think thunderbird has support to fixup a message if the mimetype of the first attachment application/pgp-encrypted. Which reminds me that we need to change the filename of our internal attachment, too to use .mim as an extension. Then you will at least also be able to open such messages on other clients with Kleopatra directly to view the contents of the mail. And a side effect of this might be that Enigmail might then be able to open the mails. If not we would need to talk to enigmail how to solve this.

So I have analyzed the problem and I think I understand it now, but I don't really have a solution yet as I think a new option or change in gpgtar might be needed. I think the easiest would be that if --utf8-strings is provided that also the --output parameter is assumed to be UTF8 encoded? And not just the files from --files-from?

Sorry, done now

This one is one me. I think the issue is gpgme-w32 spawn.

Under Kleopatra -> Settings -> Configure Kleopatra -> GnuPG System -> In the Tab Secret Keys -> Is there either "Delete unused Passwords after N Seconds or Delete Passwords after N Seconds set to zero or the option "Do not use the password cache for signing" set? In this case this would be normal and expected behavior because it turns of the caching.

Aha, so you know how to provoke us into action, good man ;-) Alright I give it high priority. No seriously, makes sense to have we'll see when we can fit it in. Needs an extension in our internal api so probably not in the next release but sooner rather then later.

Mmh or even select all expired keys and then refresh them.

Multi select makes this nontrivial. But I think only with multi select this would really be useful. But yes it is a nice item for the backlog. E.g. if you know that a company switched their mail domain you might want to refresh all the keys from that company and you could do that with filter + multi select and refresh.

This can be resolved I tested this myself and gave a beta to the affected customer which also worked for them

Eva can you please try to reproduce this? I can't really imagine that this is true since we have soooo many users with yubikeys and do a lot of internal testing on them. To be fair please try with your standard devuan GnuPG and not just with an up to date version.

Yes I can see that gpgtar correcly lists the directory with procmon, accesses the files but fails to create the output file indeed.

Not sure yes If I rather fix this or do: T6331

No need for QA on build issues.

In T6725#175868, @ikloecker wrote:

No. Windows has a file selection dialog where you can only select files and a folder selection dialog where you can only select folders. We cannot change Windows (and we will not use a non-native file dialog).

This is a release blocker for me.

Ingo can you investigate? This is very important because this is a regression caused by the change to pass filenames directly. I wonder if we pass this as UTF-8 and gpgtar needs a fix or if we pass it somehow else.

There has been another report on the Gpg4win Forum which might be related that mails now cause endless syncs and might even break further when they are saved back to the same exchange server as there is no MAPI to MIME conversion done anymore and other clients cannot read the mime structure.

As eva wrote the problem is that if you decrypt only the archive and not immediately extract it, which is an option for our users this results in a broken extension. And it also looks wrong even at first glance so it does not look like we intended this. Also wouldn't we then need mime types for the tar.p7m tar.p7s, too and tar.pgp?

Meanwhile, can you please share how to use the new feature "open the mail from the Kleopatra menu" would be nice to test it.

The most difficult thing here was to actually support the case where the user then sees the keyresolver dialog and selects "yes i do not wish to sign" this never worked.

Now when I try to encrypt to expired certificate this message comes up:

So the default error is now:

Yes I think this makes sense and a little safeguard from weird situtations where users won't know how to resolve a problem. I think we should also check for that when ever a group is opened that it does not contain such keys. In case someone "revoked" there encryption key or more commonly the encryption subkey expired. In that case a message box might make sense telling the user which key / keys are not suitable for decryption.

Maybe its not a com addin but one of the New JavaScript webapi addins? They have a different menu to disable. Definetly not an outlook feature its this protectit thingy. But have you now Trierdto open the mail from the Kleopatra menu? That is the cool New feature we are currently working on.

Ah wait, in the first of your screenshots it is obvious which addin is modifying your mail so that we don't see it as an encrypted mail anymore. It is that warning text from the protection Addin that you should report that mail if you are unsure where it came from. That would cause such problems because when it inserts this text the type of the mail is changed and it is no longer detected as an encrypted mail.

There in the last screenshot on the right. Btw. since the mail you sent me with the ZIP archive looked also fine to me, there might be another problem here. Could you try disabling your other Addons in Outlook temporarily and check if that might solve the issue? Other addons are also often a cause for some unusual client behavior. You can do that if you go to File -> Options -> Add-Ins -> Manage COM Addins, and then unselect others just for a test.

strange, your test mail in the attachment decrypted for me, too. What happens if you now use the "Show EMail" button?

Please try the following beta: https://files.gpg4win.org/Beta/gpg4win-4.2.1-beta55/gpg4win-4.2.1-beta55.exe This should solve your problem. And if not you can now open the encrypted attachments with Kleopatra and it will show your mail.

Please try: https://files.gpg4win.org/Beta/gpg4win-4.2.1-beta55/gpg4win-4.2.1-beta55.exe This should solve your problem. And if not you can now open the encrypted attachments with Kleopatra and it will show your mail.

Working on both. Beta will come later today, I had one on friday but did not upload it yet and need to recompile it first.

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.

Hi Dan,

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.

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

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.