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.

Perhaps i wasn't clear enough in the earlier messages on this thread. The inclusion of restrictively-licensed code in a file that also claims LGPL/GPL appears to be an unredistributable license. Could you please clarify why the GPL or LGPL applies to libksba while it contains src/cms.asn in its current form?

we've never shipped a binary gpgscm in any debian package. I was just reviewing the differences between what we ship and what upstream ships, and i noticed this discrepancy.

I also experienced this issue while testing my --delete-secret-key patches. Passing --pinentry-program /usr/bin/pinentry-tty to the gpg-agent worked around it.

Add confirmation prompt for exactly-specified public subkeys.

Add documentation.

Add documentation.

Thanks, the mentioned OpenSSL option should be helpful.

A high level test description is:

1. Configure both gpgsm and dirmngr to use OCSP.
2. Import the responder signer certificate with gpgsm --import.
3. Use a certificate with OCSP responder extension present, or configure a default OCSP responder in dirmngr.
4. Configure your OCSP responder to identify itself with key ID (and not subject name)
5. Attempt to sign or verify with gpgsm.
6. You should get an error, with dirmngr logs showing that the responder signer certificate could not be found.

Thank you for a quick fix (despite this being a minor problem).

Thanks for taking the time to describe this attack vector. We will need to study this closer to balance such a change with other side effects of this.

gpgscm will anyway be moved to libgpg-error and then installed as part of that package. Given that we install it for quite some time with gnupg, I won't remove it unless we can be sure that it has been installed by libgpg-error. Feel free to remove it from Debian, though,

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 do not have a PoC (or much interest in making one, I have too many more important things to do), but I believe this to be correct, based heavily on PPC knowledge of Nicolas König <koenigni@student.ethz.ch> . This attack also applies to AMD, Intel, and ARM.

Remove gpg_ prefix from function.

Squashed: D482

Squashed: D485

Squashed: D488