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:

You are running in a codepath that means "Outlook told us this was S/MIME, but we have not seen the proper message headers and neither does the data look like it is S/MIME."
Sadly your log does not help much in that case because it marked the mail as bad and aborts.
I've changed that "marking a mail as bad" so that future logs will be more helpful and that it will still try to treat this case as "encrypted" maybe that will already work, although I doubt it. The log will at least be a bit more helpful.

As I see it Bernhard is just asking for the flat strucuture so basically some export script that creates the needed files on windows.

Gets reported multiple times and should be fixed for the next Gpg4win release as it is a bad first impression. (Although it can convert users to Kleopatra ;-) )

not yet, I try to get to it this week.

I'm closing this issues as "Invalid" because it is not an issue of Gpg4win. You can still comment and discuss here.

Ok. If you can confirm that then it means that my analysis is right. Still unexpected to get an error there. I have to do some more tests with Exchange Online but that would be another issue. If this issue is fixed by turning of debugging then it will also be fixed by my patches.

While I can't reproduce it myself (because I probably don't have the right mails in my exchange) looking at your log I think that I see the problem there might be an issue with the error handling in openProperty. So for old mails the openProperty probably fails because we have exchange online for that and the property is not yet available in Outlook and then the error is not correctly handled and it crashes.