The long term goal is to replace sshcontrol by aflag in the extended private key format. This would instantly solve the bug. Thus closing.

I am preparing the patch I am using against 2.2.0. What is DCO?

Hi gniibe

While trying to identify the cause of this problem, I found that the import doesn't success with expired key.

Well, I'm able to reproduce this issue on Parabola. I was also get a different error when I turn off my vpn: `server indicated a failure```, but now I get the dns error again.

elonsatoshi@tyger ~> gpg -vvv --debug-level guru --search elonsatoshi@riseup.net
gpg: using character set 'utf-8'
gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog
gpg: DBG: [not enabled in the source] start
gpg: DBG: chan_3 <- # Home: /home/elonsatoshi/.gnupg
gpg: DBG: chan_3 <- # Config: [none]
gpg: DBG: chan_3 <- OK Dirmngr 2.1.23 at your service
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_3 -> GETINFO version
gpg: DBG: chan_3 <- D 2.1.23
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KEYSERVER --clear hkps://pgp.mit.edu/
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KS_SEARCH -- elonsatoshi@riseup.net
gpg: DBG: chan_3 <- ERR 167772876 Connection closed in DNS <Dirmngr>
gpg: error searching keyserver: Connection closed in DNS
gpg: keyserver search failed: Connection closed in DNS
gpg: DBG: chan_3 -> BYE
gpg: DBG: [not enabled in the source] stop
gpg: keydb: handles=0 locks=0 parse=0 get=0
gpg:        build=0 update=0 insert=0 delete=0
gpg:        reset=0 found=0 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=0 cached=0 good=0 bad=0
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
              outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: rndjent stat: collector=0x0000000000000000 calls=0 bytes=0
gpg: secmem usage: 0/32768 bytes in 0 blocks
elonsatoshi@tyger ~> sudo rc-service openvpn stop
[sudo] password for elonsatoshi: 
 * WARNING: openvpn is already stopped
elonsatoshi@tyger ~> pidof openvpn
elonsatoshi@tyger ~> gpg -vvv --debug-level guru --search elonsatoshi@riseup.net
gpg: using character set 'utf-8'
gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog
gpg: DBG: [not enabled in the source] start
gpg: DBG: chan_3 <- # Home: /home/elonsatoshi/.gnupg
gpg: DBG: chan_3 <- # Config: [none]
gpg: DBG: chan_3 <- OK Dirmngr 2.1.23 at your service
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_3 -> GETINFO version
gpg: DBG: chan_3 <- D 2.1.23
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KEYSERVER --clear hkps://pgp.mit.edu/
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KS_SEARCH -- elonsatoshi@riseup.net
gpg: DBG: chan_3 <- ERR 167772876 Connection closed in DNS <Dirmngr>
gpg: error searching keyserver: Connection closed in DNS
gpg: keyserver search failed: Connection closed in DNS
gpg: DBG: chan_3 -> BYE
gpg: DBG: [not enabled in the source] stop
gpg: keydb: handles=0 locks=0 parse=0 get=0
gpg:        build=0 update=0 insert=0 delete=0
gpg:        reset=0 found=0 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=0 cached=0 good=0 bad=0
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
              outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: rndjent stat: collector=0x0000000000000000 calls=0 bytes=0
gpg: secmem usage: 0/32768 bytes in 0 blocks

dcfb01959802 looks much better, thanks for the review. All tests passed.

Reverted.

Patch breaks the tests.

D441: card: Yubikey factory-reset failure is the patch.

This may fix the problem for new version 4.2.7:

Fixed in 2.1.22.

Fixed in rG69614d55018d: scd: Support longer data length for special DOs for v3 card..

For questions please contact the gnupg-devel ML.

I just verified that this is indeed fixed.

In T2923#100519, @dkg wrote:

including these tests (or something similar) in the gpg test suite would be a good way to avoid future regressions.

including these tests (or something similar) in the gpg test suite would be a good way to avoid future regressions.

The cause of the regression may actually not be in GnuPG's code.

We need to find out when this regression happened. Back when David implemented trust signatures he ran tests with the PGP folks to make sure our implementation are compatible. This is why I call this a regression.

For information, this issue was also discussed on both gnupg-user and gnupg-devel back in january 2017. I mention it here for reference.

Any update on this?

Given that this is just a warning, we should not consider it a bug.

Fixed in 2.1.21.

Fixed in 2.1.21.

Fixed in 2.1.21.

Fixed in 2.1.21.

I would also like to have attached differential included for Gpg4win if this is not too much.

I didn't mean to remove the capability of having a restricted "extra-socket". I meant that we could remove (or deprecate) the capability of placing the restricted "extra-socket" at an arbitrary location. I agree with you that having the restricted "extra-socket" is an important capability that gpg shouldn't remove.

In T3108#96369, @dkg wrote:

I think it only lists the wrong "extra socket path" when one is specified in gpg-agent.conf, right?

https://developer.apple.com/library/content/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html

Applied to master (formatting the commit log), and pushed.

Thanks, gniibe, for the quick reply.

Thanks for your explanation. Now, I got it.

T1967: GnuPG should select a key for signing without trying to use missing subkeys and T1983: gpg2 prefers missing secret key to available key on card is related, possibly.

not sure if that should be called closed as described here https://dev.gnupg.org/T3029
"This is no a bug but a non-proper installation of libgcrypt. In fact the output
of libgcrypt's "make install" shows hints on how to finish the install; also
pointing to ldconfig.

Ah, yeah, that worked. I was confused by the fact that I already have the bang in my .gnupg/gpg.conf, and got a warning when explicitely passing it to GPG.

Appending exclamation mark (!) to the keyid, you can specify exact match for the key.
I think that you can use 0xADCF72E06DBC3057! for git commit.
Please try.

I think it only lists the wrong "extra socket path" when one is specified in gpg-agent.conf, right?

Thanks for your confirmation. I pushed the commit.

You're right this function is the culprit. The

I suspect compiler optimization.
If you are with debugger, please check the function dns_ai_setent in dns.c.
When type==DNS_T_A, it sets sin_family = AF_INET. But it does some violent memory access for modern C.
Then, the value is accessed through saddr->sa_family.
I wonder if (*ent)->ai_family is correctly set here.

This is what I see in gdb after the host resolution is called:

The machine is x86_64 qemu-kvm virtual on x86_64 host.

Pushed: rG116cfd60779f: g10: invalidate the fd cache for keyring.

Cool. Thanks for your work here. Where would I apply this patch, or should I just wait until you guys have it fixed?

Thanks a lot!

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

I went through and was receiving keys individually just to see if it would work, and all of them work, except the:

Odd. I used the pubring.gpg you uploaded.
Refresh-keys successfully retrieve keys like:

That is the one I uploaded...

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.

I tried what you listed above and it worked, just like you said. I have uploaded my public keyring to look at. But other users are having this problem as well. Thanks.

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

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