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.

I found these instructions for pinentry loopback in Emacs, and they worked!

When you can configure it properly, there is a way to workaround it.

A newline is required by the PEM standard.

Maybe the file was encrypted with a version of gpg4win-3.1.5? We had a serious bug there that sometimes files were corrupted. See: T4332

Thanks for taking this one.

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.

Thank you for that analysis. I don't understand some of the parts (because I don't know anything about pinentry), but I do have some questions.

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.

fwiw, i'm used to using slashes in my branch names in dozens of other projects. I was trying to keep my branches scoped under dkg/ so that others could ignore them if they wanted. If the only issue is that i need to not do that, i'm fine naming them with hyphens instead of slashes (or whatever). I'll use that rule for future work.

gniibe wrote:

Please let me know if I can run any other tests to help debug this issue. I'm happy to help.

Just did that: slashes and dots are now mapped to hyphens. Let me know if the problem persists.

That is due to the update hook which has code like this:

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.

@gniibe thank you!

Thank you for your response.

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've pushed fa0a5ffd4997c2ca38a1dd2d89459b6b1f18ad99 to the branch dkg/fix-T3464, which i think solves the problem i was seeing without reintroducing any new problems.

I can confirm that this is actually a problem now :( gpgme_op_decrypt_verify returns a status with GPG_ERR_MISSING_KEY set when a session-key is used.