Thank you for your fix suggestion. I think your change is good. I applied and pushed.

Sorry, I responded in a mode of "tracking a bug to fix soonish". I should have changed my mode into showing HOWTO.
Thanks for sharing useful link.

This is problem of your setup of your build environment. Closing.

We got reports from Ubuntu users, perhaps, it's good to refer:

I added the section in tools.texi. Closing.

For (1): it is broken out-of-the-box, that would be true. When you can configure it properly, there is a way to workaround it. Well, I admit, it's not yet perfect.

Thanks for your report. The symptom you have could be only solved by using pinentry loopback mode, or using some special pinentry for CLI, I suppose. pinentry-tty is not sufficient for this usage.

FYI, pEp annoyance was addressed and handled here: https://bugs.debian.org/891882
By this patch: https://sources.debian.org/src/enigmail/2:2.0.11+ds1-1/debian/patches/0002-Avoid-auto-download-of-pEpEngine-Closes-891882.patch/

RFC 5280 only addresses about BCP78 and not about TLP, while RFC 5652, RFC 5755, RFC 5911 and RFC 5912 address explicitly about TLP. In this situation, I wonder if it's better to take the definitions of Extensions, UniqueIdentifier, and GeneralNames from RFC 5280. To be conservative, I don't include them now.

I pushed more changes to include modules in RFC 5911 and RFC 5912.

Comparing old cms.asn and new cms.asn, now I understand how RFC 3370 matters. I added those things back from RFC 5911 (which cites RFC 3370) which comes with BSD license for code.

I did some work (since Debian is important for us).
Please have a look at my topic branch: gniibe/fix-4487
or:
https://dev.gnupg.org/source/libksba/history/gniibe%252Ffix-4487/
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libksba.git;a=shortlog;h=refs/heads/gniibe/fix-4487

For GnuPG, the error is: you don't have run-able libntbtls.so in your environment (because of your wrong configuration, perhaps) but you have it to link.
For GPGME, the error is: your linked libgpg-error.so.0 and the one which runs are different (because of your wrong configuration, perhaps).

I wrote a patch in a topic branch: rG108c22c9c50a: g10,agent: Support CONFIRM for --delete-key.
I think that gpg-agent side,

• agent/call-pinentry.c: This part is good
• agent/command.c: I wonder if use of status for passing the information of prompt is good or not

Perhaps, we need an improvement in

• g10/call-agent.c: how to ask user, by cpr_* function with no keyword is good?
• Currently, only using DESC
• Only applying to DELETE_KEY command
• Can be applied also to:
  • PKSIGN
  • PKDECRYPT

Fix pushed.

I think that detecting strerror_s by configure is better, because it's a new feature on Windows.

I think that when using GNU autoconf's configure, you should have the ${prefix}/bin in your PATH.

Simply sending "KILLSCD" is implemented.

There is also a confusing case: a subkey expiration date is set, but the associated primary key is expired.
Pushing a fix in master.

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).

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).

Sorry, I have read the short paper wrongly. I misunderstood as if a forged key could be made using existing key.

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.6 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 (even with -std=c99).
• 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.

In my opinion, it's good if we can offer:

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