In T4318#121604, @che wrote:

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

I give this normal priority to move it out of the "Needs Triage" queue.

I think I understand what is going on here:

@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.

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.

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

@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.

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.

The tooltip:

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

I sent a message to gnupg-devel about this issue as it will probably hit more people now that the keys used are expired :-(

Oh,.. it is even worse. The conflict keys expired 2019-01-06 so they are actually expired right now.

Should be looked at before the next release.

Hi,
thanks for the report. We were unaware of the Andorid problem. The Web App issue was already reported similary.

18:25:22/11956/ERROR/mapihelp.cpp:mapi_change_message_class: can't save old message class: hr=0x80070005
18:25:22/11956/mapihelp.cpp:mapi_create_attach_table: message has 2 attachments
18:25:22/11956/mapihelp.cpp:mapi_create_attach_table: attachment info:
18:25:22/11956/ 3435173 mt=0 fname=gpgol_string_7' ct=application/pgp-encrypted' ct_parms=`(null)'
18:25:22/11956/ 3435205 mt=0 fname=gpgol_string_8' ct=application/octet-stream' ct_parms=`(null)'
18:25:22/11956/mapihelp.cpp:mapi_mark_moss_attach: Marking 3435173 as MOSS attachment
18:25:22/11956/ERROR/mapihelp.cpp:mapi_mark_moss_attach: can't set GpgOL Attach Type property: hr=0x80070005
18:25:22/11956/mapihelp.cpp:mapi_mark_moss_attach: Marking 3435205 as MOSS attachment
18:25:22/11956/ERROR/mapihelp.cpp:mapi_mark_moss_attach: can't set GpgOL Attach Type property: hr=0x80070005

Yes please use the command line ( gpg --gen-key ) or Kleopatra. This issue is fixed in the latest version of the GPGME library.

Reporter in wald said that he is using GMX with POP3. I don't see how that could change compose actions but maybe Outlook internally uses a different MAPI Provider which could cause different behavior. I have not tested POP 3 in a long time so this will be the next step here.

Please provide a summary of the talk.

My opinion:

I did in my first comment here ;-)

Yes, please send the mails. Maybe they will show me the problem already. :-)

@JW-D thanks. Please send them to aheinecke@gnupg.org

I had a report of this by mail where the problem was that:

Thanks for the report. Indeed I've overlooked this.

If it contains a gpgolPGP.dat it means that it was already parsed by GpgOL and GpgOL created the MOSS attachment from the clearsigned original message. That it's tnef is part of the export and should not be a problem.

The reporter said that it did not work for him.

@werner what should the contents of the file look like?

Asked to raise the priority on this. The quality bar issue is T2103

Good to know. I thought that ocsp-signer was only used if ocsp-responder is explitly set. I've suggested the workaround in the Message Board.

that error means that the message was somehow corrupted during transfer. Are you maybe using ftp in text mode on a binary message for example?
You could ask your communication partner to send you messages in text (ASCII Armor) mode which is more robust.
In Kleopatra you can change that in Settings -> Configure Kleopatra -> Crypto Operations -> Create signed or encrypted files as text files.
On the command line you need to add "--armor" option.

In Wald someone reports that this also appears to happen when decrypting. https://wald.intevation.org/forum/message.php?msg_id=6377 Probably run-threaded will help to flush this out.

Even with the logging changes this still happens. I just retested it. Can't run Kleopatra on Linux with GPGME_DEBUG=9.

Got another reliable report in the Wald Forum about this. https://wald.intevation.org/forum/message.php?msg_id=6371&group_id=11

No I do not think so. Because that would already be currently the case. If you had a subverted Root CA of course you can attack. But we are only talking about CRL / OCSP here. A root CA that does not provide a CRL for certificate X is OK. As long as the Root CA that issued X issues a CRL for that. Well the usual CRL / OCSP denial of service is still possible but I don't see any subversion.

I wonder if the best thing here might be another flag in the trustlist to disable CRL/OCSP checks for a single root certificate chain. I had such a request in the Gpg4win forums. Someone had a single unreacable CRL / OCSP and had to disable globally all checks for all other certs, too.

Uhm, if this option is useful why isn't it default behavior?

I'm pretty sure I tested this in the past using the Outlook.com web interface. The mails should show with an unknown attachment (the signature). I can't think of any changes recently that would have changed it. I'll check again.

I don't think this works for me in that way.

Thanks. In the meantime GpgOL takes it's language from the Outlook configured display language setting. I'll add support for override locale to gpgol so that the locale is set accordingly

Should we close this or do you want to investigate why the segfault happened after the error?

I ran it with GPGME_DEBUG and it errors out at
GPGME 2018-12-07 10:34:32 <0x19c43> gpgme_op_genkey_start:293: error: Invalid argument <GPGME>

Just by going through the standard "new key wizard".

Sounds good! I give it to me for testing / documenting this.

Is this fixed now?

Ben is not even subscribed to this issue.
With the volatility of gpgme-python I think that this can easily be merged. I did a quick review and it looked good to me.

Thanks! Applied.

Cool and yes, that could also be an option. I was explicitly told by KDE-Windows that this would work for them, too. The problem for me is that I feel comfortable to add a CMake Buildsystem for the Cpp and Qt bindings (maybe Python?). It would be very simple for me, I would not extend it to GPGME core, at least not at first. I could do that on GNU/Linux without having to test an MSVC build.
It will be more effort for me to make autotools work nicely with MSVC. I would have to test that etc.

Further discussion revealed that the main problem is QtWebengine, which is a requirement of KMail and basically a fully fledged web browser with millions of lines of code. QtWebengine is only supported for MSVC on Windows and a MinGW port is not feasible, so just compiling KMail with MinGW all the way through like I did in the past is no longer an option. :-(

I give this high priority. This blocks for years that the KDE-Windows initiative provides a way to install the very good crypto MUA KMail on windows. They rely on MSVC (you can say that this is bad, but it is a fact of life). As a former member of that community I am a bit ashamed that I made it harder / impossible for them to build KMail with MSVC because I've moved it to GPGME proper.

I think that is something I want to grapple with next year. The maintainer of KDE 4 windows noted that they currently rely on the patches from:

It might also be noted there in the installation instructions that it might be better not to run the installer from the download folder. (internal tracker issue45)

@werner Be my guest.

I'll leave the fallback to "just try to decrypt" in though because it is better then doing nothing like we did before.

Thanks, from that log I can understand the problem: