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.

Please never ever define NDEBUG. This is a severe misfeature of the assert macro.

That's exactly the point: I do want one common encryption key between the two cards: So I can distinguish between the two, but en-/decrypt with both.
One is on the GnuPG SmartCard, the other on a YubiKey - output --card-status (some things xxx'ed out) :

Here's the patch:

I contacted Microsoft Security Response Center (MSRC) in regard to this matter. They confirmed the failed PGP key verification, but have not yet any explanation for that.

Please show us your output of gpg --card-status for each card, and tell us the reason why you think "the pgp db seems screwed up".

For my test, six distinct keys (three subkeys for each smartcard) works fine.
IIUC, you try to use same decryption key by two smartcards. Currently, it is not supported.

Is it an issue when you share an decryption key E among two smartcards?
I think that when there are six distinct keys (three subkeys for one smartcard each), it works fine.
I'll try to make reproducible test case.