2.1.15 is a pretty old version. Please help us and try to replicate this with a 2.2 version and also give a log of the --delete-secret-and-public-key and --list-secret-key commands.

Great, thanks for the quick response!

Thanks for testing. I recall that I wanted to update the checking but a phonecall disturbed my hacking sequence; should have used DND.

Does this happen to you for all mails or just some? From the GpgOLXXX.dat I can't see anything wrong.
My expectation is that something goes wrong when updating the plain text into the message viewer. Again, could you please attach the GpgOL Debug output? That might help.

I have not seen this. But I suspect that it would be fixed if our encryption no longer causes Outlook to become "unresponsive". I'm already working on this for T3509 and have a development version which already does the encryption in a way that the pinentry / key resolution are just a modal dialog over outlook and no longer block the GUI of Outlook completely.

The patch is available in our downstream bugtracker as attachment to https://bugs.gentoo.org/646194

This can easily be solved by adding two more cases to handle_send_request_error(): for GPG_ERR_EADDRNOTAVAIL (that's IPv6 disabled via procfs) and GPG_ERR_EAFNOSUPPORT (that's missing kernel support). Normally I'd submit a patch but I don't care enough to jump through all the hoops just to get two-line change in.

Come on, it is in daily use for 15 years. MUA which can't handle MIME at all but PGP are still able to decrypt PGP/MIME. That is why ME specified PGP/MIME this way.

uploaded the offending key for reference:

Ah under Linux we ran into an assert which made finding the problem easy. The bug was introduced by the fix for T3602. Will be fixed in the next release. Apologies for the inconvenience.

Thanks for your report. I tried this several times. Could not reproduce it at first but I could get it to crash sometimes. Even without GpgEX just by double clicking the signature file.

Confirming this bug in Gpg4win version 3.0.3 (previous version was OK).

Thanks for the report.
Fixed in master.

I just thought that going by your comment on Sat, Jan 27, 5:29 PM that you would use libdns, instead of resolv.conf directly. Maybe I understood that comment wrong.

dirmngr looks into /.etc/resolv.conf and does not know anything about systemd specific things (nor do I). Thus having a symlink seems to be an appropriate solution.

Note that it works as expected if I symlink /run/systemd/resolve/stub-resolv.conf to /etc/resolv.conf. Other programs appear to not require this change.

I can reproduce this issue with gpg 2.2.4, systemd-resolved and Arch Linux. Unlike the original reporter, I do not have 127.0.0.1 in my /etc/resolv.conf. I do however have it in /etc/hosts.

It turned out to be a bug in Enigmail. The "," in the key list s wrong.

Checked - it builds fine now. Thanks!

I push my change to master.
Please test.

Thanks for testing master.
No, it's not typo, in my opinion.
The line was added as if it's LOCAL_PEERUID, but there is no such a thing in XNU, but there is LOCAL_PEERUUID which is for UUID.

Regarding truncation, it seems draft of the RFC has some contradicting statements. In "5.2.2. {5.2.2} Version 3 Signature Packet Format" it says:

I close this bug - if you can provide the log files please feel free to reopen.

That might be the case. I suggest to use

Please note that Section 13.6 of RFC 4880 says:

Are you sure that you are runtime linking to the same libgpg-error version you used for the build?

This would then be a 1024 bit DSA key according to the DSA-2 specification. Back when DSA was introduced to PGP the specs did not specify a truncation. Maybe because there were no hash algorithms larger than 160 bits at that time.

Actually, I was using rightmost 160 bits of hash instead of leftmost. Key below also uses DSA/1024 with SHA256, but I'm using 160 bits from the left and it can be imported correctly

Thank you, that's useful.

You can compare your key with a key generated by GnuPG.

If you look at the specs of DSA you will see that using SHA-256 truncated to 160 bits is not defined. DSA 1024 uses a 160 bit subgroup and thus SHA-256 would need to be truncated to 160 bits. If you want to look closer at that key the command

Key signed with SHA1

SHA256 key

My apologies , after the system upgrade, multiple things around gnupg broke and I got distracted and forgot to check the fetched public key, which somehow didn't contain subkey data.
This particular issue has been resolved by updating upstream public key.
Thank you for your assistance.

I use Debian stretch. It works for me with GnuPG 2.2.4.
The stub is created at the time when --card-edit accesses the card.
When I type RET after fetch command, it shows the key information.

You can't use the curve Ed25519 with ECDSA; you need to use EdDSA, The error checking when using the parameter file does not catch all errors. It should do this of course.

First, there is a documentation bug: args is undefined. It appears at the top of the man page, but nothing in the man page says what an argument is. The man page says --recipient is an "option" (but it's not, it's an argument, and the distinction is important). I broke neomutt recently because I read the GPG man page, which stipulates a particular sequence of tokens and implied that the old commandline was out of order. That is why it's suddenly a problem after 20 yrs.

Sorry, I don't understand your request. I might missing some context related to the neomutt bug, though. What I can see tehre is that gpg options are used after the option/command to arg delimtyer "--" . That is of course wrong. It might be that mutt uses a special syntax here but I can't remeber that because it is 15 years since I implemented the new crypto layer in mutt. And you should really prefer to use the use_gpgme than the >20 year direct call of gpg.

Well, that was a bit tricky to fix but it has been done and will go into 2.2.5.

From your log I can see that the verification fails with "Unsupported Protocol" which is weird in itself. But at least with the fixes for T3538 (they are included already in your version) it should then show the unverified body. So this is a second problem. I tried to reproduce this for sent mails but even if deliberately break them they are displayed correctly.

Hi Andre, thanks for your help.

Damn I thought we had all these kinds of display issues fixed now with 3.0.3. Is this really GpgOL 2.0.6? (you can take a look at the option dialog of gpgol to confirm this)

In T3739#109615, @aheinecke wrote:

The default Pinentry for Windows is pinentry-qt it should both be accessible with descriptions and screenreader API support and it should allow you to paste in passphrases. The passphrase length is limited at 255 characters.

BTW, using a long passphrase for public key encryption is in almost all cases useless. The passphrase is there to protect the private key, the passphrase is never sent to another site and will only be seen by gpg-agent, pinentry and the tty I/O software of the OS.

FWIW, Running gpg from the commandline with option -v shows the pinentry flavor.

The default Pinentry for Windows is pinentry-qt it should both be accessible with descriptions and screenreader API support and it should allow you to paste in passphrases. The passphrase length is limited at 255 characters. This limitation comes from GnuPG and is there both for Windows and Linux. Have you tested Pinentry-qt with a screenreader?

as your behavior is unusual please verify that no other Addons interfere, we are still trying to figure out if there are incompatible other addons. So please try to disable any other addons and try again.

I already talked with the upstream author and we figured a possible problem due to an non-locked use of the core function. The cause of this is

unsigned char *tmpval = ec->mem + ec->memlocation;
*tmpval = (*tmpval + 1) & 0xff;
ec->memlocation = ec->memlocation + ec->memblocksize - 1;
ec->memlocation = ec->memlocation % wrap;

which is non-atomic and will thus leads to the out-of-bounds deref. The EC object may only be used by one thread at a time.