The SEGV was due to access to gpgme library after self.wrapped is set to None in the __del__ function.

The commit is: rMb2f224a471fe: python: Reset passphrase callback correctly..

Thank you for the patch. You are right.

Looks good. After entering a wrong passphrase three times Kleopatra now reports

Moving the key to the card failed: Bad passphrase

Please reopen my issue. This is a serious issue that we encounter and do not have any explication.

Hi!
No, it's not waiting for the password. This was a 2 times error happening on our server.
We already provided the password but it was hung. We entered different things but it won't make anything.
I can tell you it doesn't wait for anything because we tested the same command on 2 different machines. On one machine it was hung, on another it worked.

gpg was waiting for the passphrase for the signing key to be provided via stdin.

With my patch I see the expected status message:

The problem seems to be that we don't return a status code with the
actual error via the --command-fd interface:

@gniibe Perfect, I got the update during the night actually. Thanks a lot for your work 🙏 .

For the firmware 5.4.3, I confirmed that it works well with the changes:
https://dev.gnupg.org/T6070#160150

Hi lovely people,

@gniibe thanks for help.

I have exactly this problem with yubikey here,
since i upgraded to gpg4win version 4.0.3 which contains gnupg 2.3.7 i get the same error as openpgp key not recognized.

@tigernero 2.3.8 is not yet released. Pretty sure gpg4win is a separate project, presumably you'll see a changelog entry here (as there is bumping to 2.3.7 in the latest 4.0.3) when it's in:
https://www.gpg4win.org/change-history.html
https://www.gpg4win.org/support.html

The provided change does not look like fixing the problem for me. The path to gpgconf is still wrong and I am getting the same error both with master and with the patched tarballs:

make[2]: Entering directory '/home/jjelen/devel/gnupg/tests/tpm2dtests'
LC_ALL=C EXEEXT= PATH="../gpgscm:/home/jjelen/.local/bin:/home/jjelen/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin" abs_top_srcdir="/home/jjelen/devel/gnupg" objdir="/home/jjelen/devel/gnupg" TPMSERVER="" SWTPM="/bin/swtpm" SWTPM_IOCTL="/bin/swtpm_ioctl" GNUPG_BUILD_ROOT="/home/jjelen/devel/gnupg/tests" GPGSCM_PATH="/home/jjelen/devel/gnupg/tests/gpgscm" /home/jjelen/devel/gnupg/tests/gpgscm/gpgscm \
  /home/jjelen/devel/gnupg/tests/tpm2dtests/run-tests.scm  
gpgscm: error running '/home/jjelen/devel/gnupg/tests/tools/gpgconf': probably not installed
(wait-process "/home/jjelen/devel/gnupg/tests/tools/gpgconf" 2693795 #t): Configuration error

I can't find a url to download gnupg 2.3.8 for windows is it possible to know when gpg4win v.4.0.4 is out which fixes this bug? because currently on windows systems I am stuck using yubikey.

It is unlikely that the tofu stuff will get into widespread use in the 2.2 version - if at all.

Fixed in master.

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