Thanks a lot!
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 24 2017
Apr 21 2017
Thank you for additional info.
gpg --recv-keys can fail when we have network problem or dirmngr doesn't work well.
I think that the failure of your original report is that it goes something wrong when it merge keys into existing keys.
It helps me if you have the pubring.gpg BEFORE you invoked "pacman-key --refresh-keys".
Apr 20 2017
This is what I noticed. This patch makes dirmngr and t-crl-parser both use same reader:
Thanks for the report.
Fixed in rG10519270d365: g13: Fix for Solaris.
I manually parse email-ca-2013.crl:
I confirmed that mingw-w64 version 1.0 defines timespec.
So, for older versions of mingw-w64, we need a fix to avoid errors.
But, your suggestion of __MINGW32__ != 1 seems wrong to me (I think it is always defined as 1).
Sorry, merging/closing is not good. This should be a subtask of T2291.
Do you configure your libraries?
Please check your system if you have ilbgcrypt 1.7.6 runtime library.
I mean: LD_LIBRARY_PATH and ldconfig.
We need to change how to access scdaemon from gpg frontend. Thus, I merge this to T2291: Smartcard interaction improvement (was: Shadowed private key design (for smartcard)), setting its priority to High. Please continue at T2291.
GPG_ERR_INV_CRL_OBJ is only possible by libksba.
I'd suggest enabling debug option for dirmngr by .gnupg/dirmngr.conf:
log-file SOMEWHERE debug-level {basic,advanced,expert,guru} # Chose one debug-all
to investigate what's going on.
Odd. I used the pubring.gpg you uploaded.
Refresh-keys successfully retrieve keys like:
Thanks. But it's wrong keyring, I suppose. What we need is not your own public keyring, but the public keyring which pacman uses.
IIUC, please upload the one in /etc/pacman.d/gnupg.
Could you please give us more information so that we can locate the issue?
I did following, but I can't replicate the problem.
(1) Save 91 of key fingerprints listed in your log to a file (arch-keys.txt). From B61DBCE10901C163 to AF7EF7873CFD4BB6
(2) Make a new directory (arch-test).
(3) Run a command
$ gpg --homedir=arch-test --recv-keys $(cat arch-keys.txt )
Apr 19 2017
Yes, 2.1.20 has the issue, too.
The crash report can be explained as: if the double-free can occur when multiple threads access to the cache at the same time, allocation in md_open may crash.
Apr 18 2017
Or provide an option to disable LDAP: T2908: dirmngr can't be build w/o LDAP
Apr 17 2017
Apr 14 2017
Yes, there are two things to implement; How gpg frontend use gpg-agent (1 in Werner's comment), and new shadowed key format support (2 in Werner's comment).
Thanks for suggestion. I'm sorry that I haven't caught this report. Now, it's assigned to me.
This is merged to T2291: Smartcard interaction improvement (was: Shadowed private key design (for smartcard)).
Apr 13 2017
Apr 12 2017
By the commit: rGf053f99ed0b0: scd: Handle unexpected suspend/resume by CCID driver., I put some code to handle such an expected return from the device.
Please try.
I couldn't reproduce this on my machine. (Suspend-to-RAM keeps my USB device running.)
Apr 11 2017
It looks like the device got suspended and resumed.
But the application (scdaemon) didn't get noticed by libusb.
So, scdaemon kept communicating as usual, but got unexpected msg type = 0x81,
which is error report status (RDR_to_PC_DataBlock).
FWIW, the syntax of "vendor-id:product-id" is used for USB for any USB tools.
Thank you for your comment.
Thank you for your comment.
FYI, when card is removed, scdaemon invalidates cache. So, #1 is already done.
In 2.1.x, scdaemon releases the reader when it finds the card is removed.
(Not for 2.0)
While I understand your request, it's complicated.
Please use GnuPG 2 (2.0 or 2.1) for using smartcard/token.
smartcard support in GnuPG 1.4 is way old and only supports shorter key length.
No way to fix, itself. Better warning/error message can be done.
This bug is not reproducible for me. I don't think it is Yubikey specific.
I suspect some failure for the transition from 2.0 to 2.1.
In GnuPG 2.1 the private keys are stored under the directory gnupg/private-keys-v1.d.
Do you have this directory?
How does it goes when you prepare another directory and specify that?
I mean:
mkdir SOME-NEW-DIRECTORY gpg --homedir=SOME-NEW-DIRECTORY --card-status