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.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jun 3 2019
Jun 2 2019
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.
Jun 1 2019
gniibe wrote:
May 31 2019
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.
May 30 2019
@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.
May 29 2019
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:
- Configure both gpgsm and dirmngr to use OCSP.
- Import the responder signer certificate with gpgsm --import.
- Use a certificate with OCSP responder extension present, or configure a default OCSP responder in dirmngr.
- Configure your OCSP responder to identify itself with key ID (and not subject name)
- Attempt to sign or verify with gpgsm.
- 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.
May 28 2019
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