I think that T5150 was also not fixed completely.

I found a bug which resulted "Not Found <SCD>" when "SCD KEYINFO" is used with "--data" or "--".
It is fixed in [rG54b88ae46}.

Fixed in master. I will backport to 2.2.

I was wrong. Patch is being updated...

Thanks. Fixed in rM7a4fe82a017b: python: Fix key_export*..

So, I'm going to push D513 to both of 1.8 and master (to be 1.9).

I can't see how it occurs. "SCE KEYINFO" and "SCD READKEY" with keygrip both goes exactly same code path (the difference is only the "action" argument).

In T5163#139750, @werner wrote:

You better wipe ecc_d_padded or use xtrymalloc_secure.

Here is a patch:

In future, please try to minimize your log. Your log actually includes information of the session of keytocard before setting key attribute correctly.

I created D513: Support macOS build with SIP by using posix_spawn in tests/random, which is more conservative; It only affects build under macOS.

BTW, I'm not sure if the claim in T5009#136688 is correct.

See also: https://dev.gnupg.org/T5009#136688

See my comment in: https://dev.gnupg.org/T5024#139701

For macOS, with SIP, some program like libgcrypt/tests/random fails, because the hack for DYLD_LIBRARY_PATH by libtool doesn't work for child process:
https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html

IIUC, for the build of Homebrew, it is the issue of in: https://github.com/Homebrew/homebrew-core/commit/e7da1e2157b2e8373c3b39ea6398f51588ea537c

Please have a look at T5024: libtool problem for some platforms for 'make check' (program built with -no-install won't work without installation), if make check works after the installation of libgcrypt.

See {TT2056}.

Last week:

• scan the Tasks
  • closed:
    • T4640: Outdated text and links at <http://git.gnupg.org/>
    • T4153: no dirmngr.log created after previous command 'KS_GET' failed: Operation not permitted
    • T4817: dirmgr keys.openpgp.org:443 Address family not supported by protocol
    • T3574: gpg-agent doesn't pick up ssh certificates
    • T3722: gpg "No name" error
    • T3524: "GnuPG MiniHOWTO" English version page unavailable
• Chased on:
  • T5055: APPCRASH with libKF5ConfigWidgets.dll
• Fixed bugs:
  • T5144: scd: Fails/crashes on SCD LEARN --keypairinfo for NetKey cards
  • T4614: GPG: Cancel on pinpad hangs decryption process for 20 seconds

This week:

• Going to close task:
  • user's problem: T5151: GPGME++ : bad passphrase problems

ARM64 has been only tested on platforms which support ELF.

Finally, with the physical device, I figure out what's going on.
The error handling in bulk_in in ccid-driver.c is not good for pinpad input.
It doesn't return an error when it is cancelled or timeout (for the user interaction).
And it calls libusb_clear_hald which causes screwed up situation.

Or it might be related issue of name server access like in T3168: dirmngr: gpg: keyserver receive failed: No keyserver available.

As of November 2020, the redirect problem has gone.
And we addressed that as "Legacy GnuPG MiniHOWTO" in rDd51cd2013e66: web: Add warning notes to most HOWTOS..

This must be an issue of SRV record retrieval.
Merging.

Support was added in version 3 card.

Because the original problem of EAFNOSUPPORT has been fixed, I am going to close this bug.

It is likely that EPERM (Operation not permitted) occurs by a system call connect(2) if you have some firewall rule(s) which forbids network access.
The dirmngr use libdns resolver which directly connects name servers.
If this is the case, you can use `--standard-resolver\ to use system's standard DNS resolver instead.

The log file specified in .gnupg/dirmngr.conf is created at the start of dirmngr.
dirmngr is invokded by the first call of gpg, and it keeps running and handle next request from second invocation of gpg.
So, nothing is problem.

On Debian, please see: /usr/share/doc/g++-mingw-w64-i686-win32/README.Debian

IIUC, the error occurred when Kleo is exiting and a destructor (in libKF5ConfigWidgets) is called with null pointer.

Fixed in rDf810f0bc5b13: git.gnupg.org: Update entry page.

For ctx->exportPublicKeys returning 0 even when a failure, (with fix of gpg) error handling should be done differently.

Applied and push the change above in rG920154370834: scd,nks: Fix caching keygrip..

For the first issue, I pushed the change in rGc3a20c88fb30: scd: Fix an error return for READKEY..

Fixed in rG006944b856ee: scd,nks: Fix SEGV for learn for older card..

Great. Please apply the patch.

More specifically, in the situation of multiple calls, ->getPassphrase is called multiple times, and it should return newly allocated "char *" object each time, because it is released each time (in lower layer).

My excuse: Please note that the support of exporting secret keys by GPGME are relatively new feature (see {T5046) and the fix rM3382ecb17eb5: core: Support exporting secret keys.). The fix of rM53ac732bae46: core: Call _gpgme_passphrase_status_handler when exporting keys. is a part of the support.
I think that we need more fixes for gpg/gpgme to be fully working well.

Please use shorter password.

Currently, gpg doesn't report any errors to status line for exporting secret keys. If needed, a patch like this is needed:

Chasing this bug, I pushed a change: rM53ac732bae46: core: Call _gpgme_passphrase_status_handler when exporting keys.

Last week:

• *.m4 update for all software of GnuPG (from libgpg-error up to gpg, and gpa, scute, poldi).
  • triggered by gnulib change
• Fixed scdaemon bug in 2.2: rG84020385be19: scd:openpgp: Public keys should be available for check_keyidstr.
• Experiment on T5139: Kleopatra keypair creation wizard improvement
• Consider about CARDNO on T5100: OpenPGP app overwrites Yubikey serial number

This week

• Zero-byte thing for Ed25519
• T5139 and T5100

Thanks, I was wrong.

How about distinguishing CARDNO and application specific SERIALNO?

Yes, it is due to a backport from master: rG1049f06c6d2e: scd:openpgp: Allow keygrip to be used to reference a key
Fixed in rG84020385be19: scd:openpgp: Public keys should be available for check_keyidstr..

I looked the gpg-agent.log, it indeed suggested the problem fixed in rG61aea64b3c17: scd: Fix the use case of verify_chv2 by CHECKPIN., which is included in 2.2.24.

You have multiple readers and using PC/SC by specifying reader-port.
We fixed in master by T4998: scdaemon: PC/SC "No such device" without reader-port, and I didn't know similar fixes should be backported.
I will soon.