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:

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.

I can understand your reasoning, it makes sense.

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)

We are always looking for ways to improve the messaging but the idea here was no keep it as simple as possible.

Depends: Not everything you see has been protected by the signature. Thus such a description would need to go into more detail.

For transparency reasons: Intevation will make Werner an offer for maintaining dev.gnupg.org.

Indeed with debug dns I can see that what takes so long is the resolve_dns_name. After the debug output prints that line the key comes nearly instant.

Still not solved.

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.

I can't replicate it here. With my key it takes
real 0m0.346s
user 0m0.080s
sys 0m0.004s
and for your key it takes a few 10ms longer (more hops). Is one of your DNS responder failing? Can you please run dirmngr with --debug dns ?

The fix was released with Gpg4win-3.0.3

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.

Bravo1, take off; control tower

'bit commit',