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.

It is reproducible on my Debian (stretch). I'm going to minimize the case.

No more reports of this since 3.0.2. With 3.0.3 I fixed an additional memleak which should further improve this. Resolved for now.

For the 3.0.3 I tested more with Microsoft Exchange Online, an Exchange 2012 Server and could not reproduce such problems. So I'm lowering the priority to normal as I don't think many users are affected.

I have exactly the same problem on my Windows 10 machine. I am using bitdefender as virus scanner, but it doesn't work no matter if it is active or not. Windows is fully updated and I am using gpg4win 3.0.3.

Have posted in gcrypt-devel mailer.. thanks

The actual problem is that justus quit his job to work for pEp. Thus we have no maintainer for the python port. There is one candidate for this job but don't expect any fast fixes because one of the near term goals will be to replace swig so that we can provide the bindings also for WIndows. Maybe that will also solve the problem with different Python versions.

it's too bad that this is not considered something worth fixing upstream -- at the moment, debian's python3-gpg will only work with one specific version of python3 because of this, which makes package transitions more complex than they should be.

Will be posting it in gcrypt-devel shortly.

Hope you've got the problem with the current naming conventions for arguments and the result by going them. We should either document the arguments properly or change the code as i have pointed out. Since the iterations argument used properly in the case PBKDF2 (type8) within the same wrapper api gcry_kdf_derive.

I would also suggest to discuss this at the gcrypt-devel list so that you can get get comments from others as well.

Your are looking at the libgcrypt code. Unfortunately that does not help us. What I would like to see are two protocol implementations, using sccryptone with libgcrypt and one with anoter scruypt implementation. Do they both work? If so, there is no bug in libgcrypt's code - at best the parameter have been given different names and we can point other name use in the docs.

Here's what i got from 1.8.1 code (downloaded from gnupg).

tests/t-kdf uses test vectors from an I-D and obviously works fine. Maybe that I-D has a different parameter naming than what is used in your examples. I simply can't say without researching the whole thing. Please let t me know a concrete bug where that KDF is not compatible with other implementations. As an example here is one of our test vectors:

With the current implementation when the r is set to GCRY_KDF_SCRYPT, on a 3 core system, it almost took 35 minutes to generate the hash, where as with r=41 it was around 4 minutes and 20 seconds.
when i corrected the the values, i.e. N=16384, p=1 and r=GCRY_KDF_SCRYPT, it took less than a second to generate the hash.

Multiple confirmations -> Resolved.

Oh dear what an evening and morning. I reversed the facts I reported. Sure 2.1 is borken - that is the whole point. ( I realized that only after install 2.2.4 and generating fresh keys). To avoid confusion I will delete my last comments.

Hi @aheinecke
Its also german:

GpgOL should use the same language detection code that GnuPG also uses. If you open a command line (cmd) and run "gpg" in that command line is it also in german?

@werner It's just simple; With --personal-cipher-preferences 3DES (3DES only), make a encrypted message. Then, try to decrypt the message with OpenPGPcard (version 2.1 and later).

I've noticed that myself and the cause for this is the code which we use to ensure that the key resolution dialog of Kleopatra opens in the foreground.

Thanks again for the test, your patience and the report :-)

:-)
I can confirm, that 2.0.6-beta14 is working and until now, Outlook did not crash :-)
Great work, thanks!

Ok so I found out that you could even trigger this bug without persistent options just by activating and deactivating any S/MIME option on a mail. This somehow changed the behavior of Outlook.

The segfault from an openSUSE machine looks the same:

In T3656#109404, @aheinecke wrote:

But that's it.
With these Options set and explicitly unchecking Sign & Encrypt before sending I get the exact same behavior that you two describe. Mails are sent unencrypted.