gpg-zip is deprecated because we have replaced it by gpgtar. Given that you have a workaround for Debian I tend to close this bug as WONTFIX.

Thanks for reporting your problem. We are highly interested in any crash. But please note that our minimum supported Exchange Version is 2010 because 2007 has reached end of life in april 2017. So I cannot test with that Server.

The corresponding fix can be found here: https://github.com/smuellerDD/jitterentropy-library/commit/9048af7f06fc1488904f54852e0a2f8da45a4745

Please note that this issue in Jitterentropy has been already fixed by upstream: http://www.chronox.de/jent.html

Default settings in Outlook are as following: (i) S/MIME encryption disabled, (ii) S/MIME signature enabled.

I'm lowering the priority as this does not appear to be a general problem. Otherwise more people would have reported it and I can't reproduce it yet.

Strange, even if I take that codepath it just works for me. Just to clarify you are also saying that if you enable "Block Outlook during encryption" it works for you? Which would be doubly strange because in your log I can see that the attachment is detected and due to T4131 we currently still always block Outlook when we detect an attachment.

I'll look into it.

Ok, I will reload the mail item then!

I can reproduce it if I enter your or an unknown IP address.

Thanks for reply.

Strange, I don't know of an issue that is related to that. There were a lot of changes to the DNS code but if you are using an IP. I've tested that using an IP works for me. I used https://192.146.137.99:443 for testing.

Indeed, I use a S/MIME certificate in Outlook for signing by default all e-mails. However, if I intend to send a PGP mail, I manually disable this feature and I manually opt for PGP signature & encryption. I am sure, that this standard procedure applied in this case. Therefore, I am surprised, that the message appears.

It worked as I expected. I've tested it with the run-messenger test and I can close and later "re-decrypt" again. The only surprising thing might be for your users that they have to unlock their secret key again if it is not already unlocked.

Right. While switching the Mail works for me if there are no other references to the mail open (e.g. If I have the mail opened in Outlook Spy switching does not work as the mail is not unloaded). It is better to make it explicit. The code is all there I just have to add a window message handler for it. I'll do that.

Thank you! The beta38 is working for me. Guess the mail->setPassWrite (true); line from the last commit did the trick. I did not need to reload the mail object again.

The problem is probably that you are also holding a reference to the mail in question. For me the close triggers an unload so that GpgOL completely detaches from the mail in question.
I've now added a more explicit tracking of when it should be allowed to write namely after our close with discard changes.

I tested these window messages with the provided beta build. Both messages gets processed and the e-mail is encrypted again but I still receive the 0x80004004 (E_ABORT) error when trying to save the message via the outlook api.

Marking this as resolved as it was forgotten in the testing state.

I think this is resolved by kleopatra's watchdog. There is a bug that the agent becomes unresponsive somehow then the loading also hangs but this is unrelated to kleopatra.

I've added two message handling routines and a small program to test it (run-messenger.cpp) You can use run-messenger.cpp for reference.

To reproduce it the key is to close Outlook through the file -> close option.

In the log I can see where it uses a non default codepath:

I don't think this answered my question -- i'm asking how adding --no-keyring affects gpgme_op_decrypt_verify -- it seems like verification would fail if no keyring is used, no?

gpgme_op_decrypt_verify can always be used instead of gpgme_op_decrypt. This is an obvious requirement because the signature and the fact that there is a signature is only known after the decryption step. The newer GPGME_DECRYPT_VERIFY of the gpgme_op_decrypt_ext function is basically an alias for gpgme_op_decrypt_verify.
For both functions gpgme employs "gpg --decrypt".

I'm fine with this change, but i do note that some people expect --decrypt to mean "decrypt and verify, if possible". In particular, gpg(1) says about --decrypt:

Hi sorry, here it is. I don't see a recommended way for providing a ton of text, so just pasting it here.

Ok. Thank you for sharing informations!

Yep, I can access this property.

Please provide a complete build log or at least the output of the configure run.

So maybe closing the inspector, too is necessary here so that the real close / unload on the mail is triggered. But it might just be that Outlook immediately reopens the mail in your case. Then it won't help but I think you should try that, too because any Interprocess communication will be more effort.

It happens with 3.1.4, too.

Works nicely now. I added a "yellow" warning to indicate that the message is a crypto message that can't be handled by GpgOL in the Junk folder. I see no way to actually decrypt in the Junk folder as we are not allowed to access attachments.

In T4241#119944, @msc wrote:

I wonder if it would be possible for you to close the mail / inspector of the mail with DiscardChanges before doing a save as?

Discarding changes with the Close(OlDiscard) method has no effect on the issue.

or, more accurately so it matches the C api, perhaps gpg.constants.import_status

Yes that is expected, we block the save event as long as we have replaced the Body / Attachments of the mail with decrypted contents are shown. In our debug log you would see the message "Canceling write event".

Yes, I can confirm that log entry.

Yes I see the problem and have a fix for it. I'm just trying to make it nice now :-)

Yes, I also can't decrypt the files there. As Outlook warns about
restricting access to attachments and active contents, the reason is
clear. The mail must be moved elsewhere.

I can reproduce that it won't be moved.

This issue is pretty old and I think anything here was fixed in recent releases. So let's close this to avoid artifacts in the tracker.

A wait, we have T4203 for the continuing problems. So let's close this.

This was likely one form of T4111

There is still at least one report claiming that this still happens for large attachments. I could not reproduce it.

This was fixed with the Gpg4win-3.1.4 release. Apologies that I forgot to mention a pre release version / installer in this issue.

I've tried to reproduce it but failed. Even If I open the message in a new window or a new explorer the message is correctly caught.

Yes that is expected, we block the save event as long as we have replaced the Body / Attachments of the mail with decrypted contents are shown. In our debug log you would see the message "Canceling write event".

Looking at the GPGME code the ERROR stati don't matter because they are only used to return a better error code in case an operation failed. The specific ones are not even recognized.

No info received.

No more complaints thus time to close.

I consider this bug to be solved.

MacPorts doesn't currently ship the bindings at all, but I'll see what they need to make that a reality too.

While this is now ideal for Debian, it may cause conflicts with other downstream vendors with slightly different needs to build their packages. In particular the FreeBSD ports and/or pkg system.

Yes! Thank you very much. My test runs and my Outlook has verified 2500 S/MIME Mails without a crash.

The explicit check for a valid FD (in select) I mentioned above is commit 8173c4f1f8a145c4b1d454f6f05e26950e23d675

I'm currently looking at the CloseHandle in _gpgme_io_close:

Btw I've checked that the errors are the same in T4111 and this:

Fixed it myself as I confirmed the leak with Dr. Memory.

I've seen now four crashes in _gpgme_io_spawn. I've added tracing that shows that the CreateProcess itself is crashing. I do not see how this is possible. I'm printing the command line and the program name in debug output and both look fine.
The command line is also mutable.

I'm also seeing hangs. Sometimes with gpgsm running. Sometimes without it running.

We had this idea to have a label: or similar item in the extended-key-format which is displayed in addition to the other info. The user can then use an editor to put whatever she likes into this field.

IIUC, in Gentoo multilib (or other distributions), <triplent>-{gpg-error,libgcrypt,libassuan,npth,libksba,npth}-config script is used.
In forthcoming libgpg-error 1.33, single gpgrt-config is used for all architecture, by having --libdir option at invocation time.

Actually we plan to provide a more convenient way to perform the DH operation. See for example P7 for the non-elegant way which is required today.

Did you have the chance to try it out with 3.1.4?

Sorry, there is no good way, but only workaround in this case, because it is complicated and it is basically wrong thing to do it by composite device (in my opinion). I'll describe detail in this comment.
I'm not Windows user, so, I don't have an idea how to recover from such a situation.