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.

1. Collect all data in OOM, then start a thread to do the encryption.
2. Do a proof of concept that this actually works and outlook lets us do it with our usual window message async handling.
3. Update my Keyresolver patches in Libkleo and build a "libkleo-tool" to do the key resolving.
4. Figure out Window Management / Create a Qt Overlay over the Mail window to block it from closing while encryption happens. This will resolve all bugs related to window mangement of the current key resolution.

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:

Your welcome, I can remake another unified patch if need be. I was starting to prepare things to be a stand alone fork. Did an initial .travis.yml file, and initial stuff for Coverity. Though never did get a build uploaded to Coverity. Not sure if you have ever run pinentry through Coverity or other GnuPG stuff, may be a good idea just to see if it catches anything.

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

Thanks for the long explanation. I think it should go into pinentry proper. I will have a closer look on it.

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

Oh. T1447 only referenced SRV records, which is why the CNAME case wasn't handled. So T1447 was fixed completely but T1447 did not cover the full extent of the underlying problem.

Key signed with SHA1

SHA256 key

@werner no problem with re-opening. I closed as it seemed it was not of interest or wanted. I wasn't get any responses like asking why it was left out of 1.1.0 release. To my knowledge other than preferences of GnuPG devs, changes to suit your needs, grabbing, libsecret, etc. It should be good to go without any issues. Thus I was waiting next release, assuming it was already committed . May have confused it with some other PR that was committed. But there should not be any outstanding issues preventing it from inclusion. If there are it was never relayed to me. It should be ready for inclusion, less any requested changes.

@werner no clue, I thought it was merged in at some point. I could have sworn something happened there. I went on advising others like the TQT interface assuming EFL was already added. I was shocked it was not when release came out and no explanation as to why it was excluded.

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.

@aa: this is not a platform to share arbitrary data or fun stuff. Please use some other service for this.

Oh yes, I should re-open this because we should keep on tracking the status - either for an included EFL version or an external version.

I have not followed this bug for the last 6 months and meanwhile @justus and @neal moved on to the pEp company and are not any longer available to work on this. Although, I made the last pinentry release I do no closely follow the development. What I noticed is that we still don't have an EFL based pinentry despite that I explained them several times that I would like to see EFL in pinentry proper. I can't remember what the Mike Blumenkrantz version is or that there have been two pending versions at all. The thread is pretty long and I have note read it in its full length.

In T3714#109752, @werner wrote:

I have not checked whether we make this available in the GPGME API

Proceeding with a fork, and likely will remove other interfaces and just maintain another version of pinentry for EFL. Maybe renamed to pinentry-efl, and only have that and tty and curses interfaces in addition to EFL.

One of these TOFU bugs. Thanks for the good bug report.

There can't be an MDC warning if MDC is not used ;-)

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

As far as I can see GnuPG does not emit appropriate status lines: