Done for libgpg-error.

Topic branch of libgpg-error is not good to show changes (for other libraries).
So, I made D473: Introducing LDADD_FOR_TESTS_KLUDGE to enable 'make check' with LD_LIBRARY_PATH.
Appliying to libgpg-error.

Indeed in view of this data, it seems to be that the problem occurs by Microsoft. It fits also with the fact, that all other signatures are working fine from my experience.

I agree. It seems a MS trouble. It remembers the trouble that you have when send email of new version available for your software. Something modifies the signed content.

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

Andre,
Were useful for you the files that I sent yesterday? There were extracted using MFCMAPI MFCMAPI tool once emails were collected but before opened by Outlook. When it's checked one of them fails to verify signature. Other two are ok (diferent origin but the same key).

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

A pristine file I do not have, because every file passes GpgOL before displayed. I suggest, you subscribe to the service and if you de-install GpgOL, you should obtain a pristine file.

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.

No, I can´t confirm it, I get no reason displayed. The key which I use is shown in my screenshot (I´ll send by e-mail)

The tooltip:

I must make a correction of my earlier statement from today. The three Microsoft messages were not displayed in the same order on the screen on both machines. I must say, that on Outlook 2016 AND Thunderbird PGP verification still fails by "Microsoft Security Update Releases". It is the same situation as last year, nothing has been changed. I sent two files in EML format and some screenshots to A.Heinecke today.

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

Yesterday Microsoft issued three PGP signed mails. It is the first communication after MSRC confirmed failure of verification and promised to have internal procedures changed. I received those mails on two different machines, one equipped with Outlook 2016, the other with Thunderbird. Last year all messages failed on Outlook and Thunderbird, if the were issued from "Microsoft Security Update Releases".

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.

In another project in the early 2000ies we had a lawyer from one of those Königsallee lawfirsm as partner. IIRC the estimated cost for a word trademark in the EU, US, and JP was in the range of 10k for just a couple of years.

I don't know why @BenM closed this bug given that he mentioned that the qt part is yet not solved.

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

We've run into the testTofuConflict failure on NixOS. gpgme v1.12, gnupg v2.2.12.

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

Just trying to find out who spoke about _which_ website _exactly_. Obviously, it wasn't just about GnuPG e.V.

Just talked to Michael Stehmann again. He added some useful thoughts. Unfortunately, he didn't agree to summarise them in 2-3 paragraphs. So I'll try...

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.

For other distros, it seems it's quite old issue: https://sourceware.org/ml/binutils/2012-05/msg00037.html

My patches on the topic branch: https://dev.gnupg.org/source/libgpg-error/history/gniibe%252Fdisable-new-dtags/

In my patch, for OpenBSD and FreeBSD (well, other than GNU/Linux), it uses getentropy if available. For GNU/Linux, we use the local macro of getentropy (regardless of the availability of the function), keeping exactly same behavior of syscall with __NR_getrandom.

Please provide a summary of the talk.

My opinion:

Can i generate a key using shell?

Version gpg (GnuPG) 2.2.11

Version of gpa and best also of gpgme? The latest gpa releases show that in the About dialog.
The installed version of gpg is also of inetrest. In a shell enter "gpg --version".

Talked to Michael Stehmann. First questions to be decided before estimating the efforts:

At end of 2018 we had a talk with designer Markus Maier in the Düsseldorf Office.
The issue was handled as well.

I did in my first comment here ;-)

Update to prefer syscall on GNU/Linux (no need to audit libc implementation):

Please, provide e-mail address, then I´ll send it asap

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

Very strange, but I tried it by myself, after your mail. The same for me. However, I can offer you to send two mails to you as EML files, one works, the other not. I using GnuPG also for verification from BSI newsletter, it works fine there. The problem is only with newsletters from "Microsoft security update releases", other Microsoft security notifications can be verified as well.

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

Yes, GpgOL in version 2.3.2 fails to verify the original message, it is labeled as "not-secure". But it happens only to "Microsoft security update releases", not to other Microsoft Security Notifications which I receive on regular base. I contacted Microsoft Security Responce Center (MSRC) and they confirmed the failure of signature verification in this case. They were not aware about it, but checked it by them self after my mail. They had no explanation for that. Labeling the message as "not-secure" would may indicate that it would be altered in transport, but MSRC did not say that. Therefore, I still assume, that we have a bug in GnuPG.

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.

My tentative conclusion: When (GNU) ld supports --disable-new-dtags, add it to LDADD in tests/Makefile.am.

Thanks a lot for your logs. I see what's going on here.
For some reason, Yubikey keeps running after failure by suspend/resume (perhaps, because it serves for multiple functionalities of USB HID for OTP, as well as CCID for OpenPGPcard).
This failure mode is not expected by the current implementation of scdaemon, under in-stock CCID driver.

Right. We won't change that though. Sorry.

Attached the wireshark log

The workaround in T3825 is for PC/SC driver. So, it is not the case for internal stock CCID driver.
'scd reset /bye' does not let the scdaemon do reset process of the card itself. It resets the transaction of scdaemon.