success, thank you for the help!

In GnuPG 2.1, secret keys are under control of gpg-agent. Currently, it is not deleted by gpg frontend.
Please run:

$ gpg -K --with-keygrip

Please try this patch:

Given no feedback, I'm closing this issue.
If there is still problem, please reopen.

IIRC, rfc2440 did not forbid partial length encoding for key-material so gpg could use that. rfc4880 limits partial length encoding to non-key-material which causes this error message.

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

Well, I'd expect gpg not to alter my digest/compression preferences when changing my cipher preferences and vice versa. So if a user's going to have to lose his previously set preferences for a key in this manner because that's the only reasonably viable way of maintaining backwards compatibility, I think it would be appropriate to let him know beforehand and also suggest that he set it all up at once (as I've so described above) so that nothing is lost in the process.

The way the setpref command works is implementation specific and thus the OpenPGP standard is irrelevant here
.
Are you requesting a change in the behaviour of the setpref command? That would not be easy to implement for backward compatibility.

I would suggest that MUAs who care about privacy do no use S/MIME at all or at least direct GPGME to not consider CRLs during signature verification. We don't have such a feature in GPGME right now but I think that is the right place to add it. X.509 is way to complicated to avoid meta data leaks.

I would also like this feature. I currently use a pair of subkeys (one for work one for personal projects) and it would be much easier if I could configure gpg-agent to append comments to the keys rather than displaying (none). Perhaps a flag could be added to sshcontrol which allows you to specify and arbitrary comment?

Perfect! This works exactly as I wanted. I indeed use Fedora 26, adding this line below to my .bash_profile works perfectly with the Yubikey to find the gpg keys on it and use it for ssh.
export SSH_AUTH_SOCK=$XDG_RUNTIME_DIR/gnupg/S.gpg-agent.ssh

Please use the systemd unit files as shipped upstream. This allows the agent to be launched automatically whenever someone tries to use one of its sockets, but doesn't pre-emptively launch the agent until needed.

Hi. You can start gpg-agent using gpgconf --launch gpg-agent. I'll delegate the systemd questions to Daniel.

To make this work again, I think gpg-agent needs to cache the public key or support batch-operations (which would require some restructuring in gpg to request such a batch-operation).

Werner indicated that the current behaviour is intentional.

GPGME does not use gpgv. What Justus likely meant is that we would need to change the common code used by gpgv and gpg. That may give problems in GPGME.

Can you describe the problems it would cause for gpgme? gpgme already currently expects that gpgv will return a failure for signatures made before the validity window of the key. so gpgme won't break just because gpgv is capable of returning a non-zero response.

Funny. We should make show-unusable-subkeys the default to detect such flaws ;-)

Re-opening.

This is not about faked-system-time, nor about misconfigured systems, it is about gpg using uninitialized or invalid data. This is one instance of that problem, and there could be more. I'm sorry if I failed to communicate this.

Also note that --faked-system-time is a debugging aid and nothing you should use under production. A wrong system time is a security problem anyway because it invalidates assumptions gpg takes. A small clock skew is annoying but the way to avoid is is easy enough.

We are in feature freeze and changing the status code of gpgv will likely cause problems for gpgme. We need to defer this.

I'm closing this. Feel free to reopen the bug with more information.

I also have to add that, if this really has been resolved, it only covers up the case if the missing subkey(s) is/are on the smartcard(s), it does not solve the problem when none of the missing signing subkeys are in smartcards (as in, all on different computers). And it's clear that for version 2.1.22, it fails to get the available subkey on the disk for this case.

@gniibe: I've tested 2.1.22 (from Debian experimental) and, while gpg --sign works, other programs (eg: git tag -s) still prompt to insert the card of the first signing subkey, despite the card with the second signing subkey being present.
Is that expected?

I implemented a possible fix in D442. The GnuPG Agent may call an external program (specified with the new --passphrase-checker option) to evaluate the passphrase's quality. This would allow to implement all kinds of metrics for passphrase strength, and to select one simply by choosing the right passphrase-checker.

I think that's fixed now.

Fixed in ebc65ff45 by always saving to standard path.

It's there in GnuPG 2.1 for a while, and bugs introduced by change were fixed.
So, I'm closing this bug.

@fogine , I'm afraid your comment is related to this bug particular report of T1983: gpg2 prefers missing secret key to available key on card.
And your problem cannot be replicated by my environment with 2.1.22.
If you still have the issue with 2.1.22, please open new ticket.

I think that this issue is fixed in 2.1, which use KS_FETCH instead of KS_GET with fingerprint.
Please test with 2.1.
We don't change 2.0.

gpg (GnuPG) 2.1.21
libgcrypt 1.7.8

GnuPG 2.1.22 in Homebrew is out: https://github.com/Homebrew/homebrew-core/commit/39a392ffd6ac20a36ea8a4aec5c4dc5febcfc1d6
Please check it out.

The maximum passphrase length is defined in agent.h:

why should it wait for the timeout in the pselect call? shouldn't it be able to respond immediately to the final connection closing?

Yes, that commit was in 2010, but it was on the 2.1 branch, which never saw wide distribution until this year, which means that there are test suites (like the one mentioned in request-tracker) which simply fail hard when used against gpg 2.1. Is there explicit guidance that the GnuPG project wants to give to downstreams like request-tracker?

Works in my tests. Thanks.

Something still fishy.

I am pretty sure that was also fixed by rGa0d0cbee7654 for T3308

Well, iff we implement that for gpg we also need to implement it for gpgsm.

We can't do anything about thisfor the oldversions. You may use libgcrypt 1.8.0 which has a faster entropy collector and also allows to map /dev/random to /dev/urandom using the new /etc/gcrypt/random.conf

Fixed in 94eea0ed2c8b47cb0fe02b22cbe668705a5fe0d0

.

gpg 1.4 only gets important updates.

This is solved easily by using "--yes", which sets the force flag on the DELETE_KEY operation. This prevents gpg-agent from doing a confirmation.

Here is what Vinay Sajip wrote:

According to the link above, the reason we need entropy on import is the KEYWRAP between gpg and gpg-agent. The reason we are stalling is that we use getrandom() and the urandom pool is apparently not initialized on that system.

Sufficient workarounds have been found.

That is the way I get my certificate signed, there is nothing I can do about it ;-)

It takes a couple of seconds for dirmngr to terminate after closing the last connection, maybe due to the timeout in the pselect call. Apart from that, it works as expected.

It's not really a good idea to use the same RSA key for encryption and signing. (Although when I wrote scute, I couldn't generate a CSR for the encryption key, because the CSR had to be self-signed, meh).

Well, the 16 byte fingerprint is used for MD5 (old v3 keys). Those aren't supported by default anymore, but the comment indicates that discerning existing entries is difficult.

What catches my eye is that emergency_cleanup() is not guarded from being invoked twice in the way that got_fatal_signal() is.

Besides -v, --status-fd 2 (for example) also shows useful information, as usual.

You get more information with -v. Because a key can have multiple subkeys, this is not so easy to fix, because at the point that we decide that we can't build the signature we don't have all the information on potential key candidates anymore.

The last time GOOD_PASSPHRASE was emitted was in 67934a8c1 (parent of 21b0a955) in 2010. I think that's just water down the river at this point.