In master, I pushed a change, closing.

For future, it would make sense applying your patch, but I wonder if it works on macOS.
Let me check.

I located the bug in agent/command-ssh.c.
Our practice is two calls of gcry_sexp_sprint; One to determine the length including last NUL byte, and another to actually fills the buffer.
The first call return +1 for NUL byte.
The second call fills NUL at the end, but returns +0 length (length sans last NUL).

Last week (major decision for TTXS, and minor fixes for GnuPG):

• TTXS: decision to use libccidtwin.so for host deriver
• gpg:
  • Add a feature to allow same key on different cards (no matter SERIALNO in the stub): T2898: Option to ignore card serial number (to be able to use backup tokens containing same subkeys), T4301: Handling multiple subkeys on two SmartCards
  • Fix T4494: UBsan finding "armor.c:1159:11: runtime error: member access within null pointer...", T4504: Asan findings in iconv configure test causing config failure
• nPth:
  • Fix T4491: Compile error in nPth's t-fork.c on Solaris 11.3 i86pc
• libgpg-error
  • Fix T4498: Asan findings in tests/t-logging.c
• Chopstx: version 1.15 release

This week:

• TTXS: implement and build test environment for CCID on serial (GemPC Twin smart card reader protocol)
• (FYI) FST-01SZ shipment to Free Software Foundation, for its online shop.

When having a backup media, I'd recommend completely different one (for example, on paper using paperkey to be stored in a locker in basement), which requires different method for recovering. Brains may be easily confused when same private key material exists in multiple similar devices.

@blades: This feature will be available in GnuPG 2.3, which is planed to be released this year.
For Debian, Buster will come with GnuPG 2.2.12. After release of GnuPG 2.3, backport might be available (like GnuPG 2.2.x is available as backport for Stretch).

Feature supported in master.

The change is adopted. To close this patch, I take over.

It's complicated to have a good solution, because we need to change assumption (serial number identifies keys).

While I think that building with GCC 4 on Solaris 11/12 is minor issue, requirement of newer POSIX API (on GNU/Linux) would be a bit serious issue.
I pushed my change to fix this.

While original npth-1.9 can be compiled with newer gcc (>= 5), we'd say please use CFLAGS+=-std=gnu99 with older gcc, as workaround.

I figured out:

• Removing -D_POSIX_C_SOURCE=200112L works both of gcc 4.9 and gcc 5.5 on Solaris 11.3.
• Then, adding -D_XOPEN_SOURCE=500, gcc 4.9 works, but gcc 5.5 failed by another error (Compiler or options invalid for pre-UNIX 03 X/Open applications and pre-2001 POSIX applications)
  • I confirmed gcc 5.5 defaults to -std=gnu99

Thanks for your offer. I have an account for GCC Compiler Farm. I'm trying with gcc211 machine. will back soon.

It looks like somewhat complicated more. It seems that specifying _POSIX_C_SOURCE=200112L is not good on Solaris with old GCC. Perhaps, it would have no problem with newer gcc (or -std=gnu99 option).

IIUC, -std=c99 won't solve this issue. It is Solaris specific C99 issue.

Thanks for your report.
Let me handle issue by issue.

Thanks for your report.

It is because you don't have ${prefix}/bin in your PATH.
Please build having /var/tmp/bin in your PATH.

Thanks for your report.

Last week:

• TTXS 0.0 released
• Chopstx USB driver API
  • Finally, I realized that a practice of STM32F103 having a gate for D+ is questionable (it was kept by confusion, in my opinion).
    • I was able to understand by comparing modern MCUs (like STM32L432 and Kinetis L, which require no external hardware).

This week:

• Chopstx new release
• gpg-agent change using KEYLIST --list
• Learning about PC/SC-lite serial driver support

Last week:

• Heard of a tool: https://github.com/rot42/gnuk-extractor
  • which only works when the board is not locked.

These Three Weeks

• TTXS: Works well
  • Another hardware: Nucleo-32 STM32L432: https://www.gniibe.org/memo/development/ttxs/ttxs-hardware-another.html
  • Chopstx port to STM32L432: Cortex-M4 (no FPU, no DSP yet), USB (almost same), USART (more features, not used)
  • Change for STM32L432, ldscript, Makefile
• operation by keygrip: scdaemon part looks OK
  • scdaemon: Added: KEYINFO [--list] command
  • scdaemon: Testing PK* command with <40-char-keyid-which-is-considered-KEYGRIP>
• Bug fixes, including:
  • GNU AWK 5.0 support: libgpg-error, gnupg
  • Japanese Translation

This week

• mostly off
• consider about using scdaemon's KEYGRIP operation by gpg-agent

The patch touches src/Makefile.am. You need to run automake to update src/Makefile.in.
In the patch, it uses pkg_namespace variable to have prefix 'errnos_'.

I think I identified the bug. A fix is pushed.

Before the SEGV, calling a handler in _gpgme_io_close is strange:

GPGME 2019-04-11 12:24:58 <0x660e>        _gpgme_io_close: check: fd=0x22 invoking close handler 0x7f341d8b8960/0x7f33f0003930

Because the file descriptor 0x21 and 0x22 is allocated by _gpgme_io_pipe, and there should be no handler(s) for those fds.
Either, the notify_table is screwed up, or there is a leak of fds.
I'd like to see the logs of all calls of _gpgme_io_set_close_notify and _gpgme_io_close.

Sorry, I overlooked. I think it is inside _gpgme_io_close calling the handler, and the handler segfaults.

Apparently, it SEGV-ted itself by assert at line 468 in gpgme/src/engine.c.
For GpgSM, info->file_name is not assigned (while it is done by gpg and gpgconf).
The code hasn't been changed for a while, I don't know the exact reason why it becomes occur.

I think that the bug has been there. The commits of import.c revealed the problem with your particular input.

Thanks for your report. It was good you add "enter no passphrase for Alfa Test Key". Then, I saw the leak. (I misunderstood as if I needed the test environment.)
Anyway, I'm going to fix it now.

Added a fix to GnuPG, too (master and stable 2.2).

I keep this ticket open, since it is also problem for other packages.

For what I use, please refer: https://tracker.debian.org/pkg/gcc-9

Today's topic:

• I realized that: Even for experiment/debug purpose, having VID:PID is useful
• In many cases, configuration of access control is done based on VID:PID
• Ask FSIJ to assign PID for TTXS

@kloczek , it is not reproducible for us, so, we consider it may be a problem other than GnuPG itself, possibly, some specific build configuration parameter(s) for GCC, or something by unreleased code.
Please file a report with how to reproduce your problem.

Busy working/struggling for TTXS.