I tried to reproduce this as we had similar problems in the past, but for me this works with full unicode characters.

Hi Marcel!

I just confirmed that firmware 5.4.3 works fine with the changes (to be 2.2.37 and 2.3.8).

Sure... it's really more of a cosmetic issue. Even without verbose mode, it should become quickly clear to anyone.

New release of libassuan is expected to make sure it's cleared off.

What I found: When the page is served by the server, it omits "charset=utf-8" part. This is the issue.

I used to have the option of generating PGP Keys up to 4,096 key size. That function has completely disappeared.

Probably fixed meanwhile in 2.2.
Please re-open if experience this problem also with a decent gnupg 2.2 versions.

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.