Probably an invalid specified keyserver

Thanks for fixing.

That is not easy to change because we show all kind of error codes. If you run in --verbose mode you should see more info.

Thanks for reporting.

The first thing is a problem of the GNU makeinfo tool. Can't be fixed int the source.

Please ask your card vendor.

@gniibe Thanks!

In the repo, for all related software, it's done.

Note that versions since 2020-11-07 to 2021-07-03 have major problem with non-POSIX shell, which doesn't support $(..) construct.

But then again: The three other apostrophes that occur in the text are represented by single quote characters. Maybe sticking to ASCII characters is the better fix after all.

Typographically the apostrophe character ’ is a different character than the single quote character '. So, the correct fix would be to fix the probably wrong encoded apostrophe instead of replacing it by a single quote character.

as of 2.3.7 (which I just updated to) this works. ticket can be closed

Thank you.

Please give us more information.

• Do you change SSH program?
  • If so, please check if adding configuration https://dev.gnupg.org/T5935#157674 for ssh works.
• Do you mean, reinstalling gpg 2.3.4 fixes your issue?
• Are you using with smartcard/token? Which one (Yubikey/Zeitcontrol/Gnuk), if it's the case?

Yes, this sadly happened with 3.1.23 for Gpg4win 4.0.3 this was noticed and fixed with rW3cdf0b10d39c844b6f3557a85dc39dc2b9242b53 as we are planning 3.1.24 anyway this issue pushed the timeline for this a bit earlier so we should have a relase very soon.

Fixed.

This regression was introduced by rLIBKLEOf9cb0d3f03c6: Port filterRegExp to filterRegularExpression.

Thanks to @mistydemeo
The patch was quickly applied to homebrew.
https://github.com/Homebrew/homebrew-core/commits/9f1ab1ce5c5d2edbe954644a52dc9ef60df5bfa2/Formula/gnupg.rb

Thank you for your report.

Does Yubico furnish you with devices for test...

Ah thanks, missed that one somehow.

Thanks @gniibe. Does Yubico furnish you with devices for test, or did you have to order that at your own/the project's expense?

You may be interested in https://dev.gnupg.org/T6070#160227

Thank you all for your quick feedback.

I've confirmed the patch fixes the issue. I'm planning to backport it to a revision of 2.3.7 in the Homebrew package manager.

I'm the user OJFord referred to above (my access to this bugtracker just got approved this morning). I tested the rGf34b9147eb30 change on my Mac, and it does indeed resolve the issue there.

I haven't had a chance to try it myself yet, but another user writes in the Reddit thread linked above:

It will be in 1.10.2.

It will be in 1.10.2.

Applied to 1.10.

Thank you for your confirmation.

Hi there!
I can confirm this regression on my yubikey 5 Nano with 2.2.36 (2.2.35 works) - on archlinux. Yubikey firmware 5.4.3, ed25519 keys too. Some more info:

I'm going to backport this to 2.2, as it found useful.

Yes, I am using ECC keys:

Key attributes ...: ed25519 cv25519 ed25519

It's in 2.3.7.

Fixed in 2.3.7.

And 2.3.7.

Fixed in 2.2.36.

Perhaps, rG53eddf9b9ea0: scd: Fail when no good algorithm attribute. should be backported to 2.2.

Fixed in 2.3.7.

Thank you. I learned that there is new firmware, version 5.4 series.

@gniibe Thanks - mine's 5.43. (And the working 4Nano is 4.34.)

In gnupg/common/ttyio.c, the function w32_write_console does:

• Call WriteConsoleW, and when it fails, it calls
• WriteConsoleA

Please let us know, your firmware version number (in bcdDevice) by lsusb.

I suggest to submit a patch with the changes you'd like to see. Please read
https://dev.gnupg.org/source/gnupg/browse/master/doc/HACKING
for information how to contribute to gnupg.

I can confirm this issue with a 5C Nano returning the error, but a 4C working successfully. Downgrading to 2.2.35 does resolve the issue.

I wouldn't call that particular thing technical specification, because it really has potentially a strong user visible impact (i.e. expected passphrase works or not - both cases, whether any other newline characters are included or not, as well as whether it would simply ignore any characters beyond a maximum length).

I'm not sure whether the manual page should be blown up to a full technical specification.

It looks like having it set will stop fallback from working entirely? Would you say that this cannot be fixed if WAYLAND_DISPLAY is set like I do above?