So i see a couple options:

a) We import a secret key -- this requires that we launch the agent to store it.
b) We import a public key and see that its preferences do match our
implementation -- in this case, we don't need to talk to the agent, right?
c) We import a public key and see that its preferences do not match our
implementation -- in this case, we could check whether the agent has the
corresponding secret key, and if it does, we could complain to the user.

instead of (c), though, we could trigger such a test the other way around: if
we're using a secret key and we notice that its public preferences don't match
our implementation, that's when we could warn the user about the mismatch.

So i've tested this locally with:

    export GNUPGHOME=$(mktemp -d)
    gpg --quick-gen-key 'test user <test@example.org>'
    gpg --armor --export-secret-key 'test user <test@example.org>'

(choosing no passphrase during the prompts that come up during the quick-gen-key
step). The final export step works fine.

Can you show what steps you're taking that fail for you, Andre?

sure: using the attached "dkg.gpg" file (a pruned version of my own public key),
i did:

if --list-config is deprecated, should it emit a warning? doc/gpg.texi shows no
mention that it is deprecated, or that "gpgconf --list-options gpg" should be
preferred.

Also, i note that --list-config is still used in the test suite:

tests/openpgp/defs.inc uses it with "ciphername" and "digestname", and
tests/openpgp/defs.scm uses it with "ciphername" and "digestname" and
"pubkeyname". I don't see any way to get the same information out of gpgconf.
Perhaps gpgconf needs to provide some equivalent?

hm, there is also:

    gpgconf --list-options gpg | \
         awk -F: '/^default-key:/{ print $10 }'

It's not clear to me when anyone should use "gpgconf --list-options gpg" and
when they should use "gpg --with-colons --list-config".

Is there some place where one or the other is more important?

I note that if i restart dirmngr it will just choose a new member of the pool
and that member will work.

hm, if there's a guarantee that scdaemon will only ever be launched as a
subprocess from gpg-agent, then maybe we don't need it.

If there's ever any expectation that some other program will launch scdaemon,
then it would be nice to use the unified launch mechanism provided by gpgconf.

fwiw, the documentation says:

       --try-all-secrets
              Don't look at the key ID as stored in the message  but  try  all
              secret  keys  in  turn  to  find  the right decryption key. This
              option forces the behaviour  as  used  by  anonymous  recipients
              (created  by  using  --throw-keyids  or  --hidden-recipient) and
              might come handy in case where an encrypted message  contains  a
              bogus key ID.

but that behavior is in fact not the default when used with anonymous
recipients, either:

2 dkg@alice:/tmp/cdtemp.hphmpn$ gpg --decrypt test.asc
gpg: encrypted with RSA key, ID 00000000
gpg: decryption failed: No secret key
2 dkg@alice:/tmp/cdtemp.hphmpn$ gpg --no-skip-hidden-recipients --decrypt test.asc
gpg: encrypted with RSA key, ID 00000000
gpg: decryption failed: No secret key
2 dkg@alice:/tmp/cdtemp.hphmpn$

I can confirm that this is still a problem on 2.1.13: --try-all-secrets does not
work as documented:

2 dkg@alice:/tmp/cdtemp.hphmpn$ gpg --try-all-secrets --decrypt test.asc
gpg: encrypted with RSA key, ID 00000000
gpg: decryption failed: No secret key
2 dkg@alice:/tmp/cdtemp.hphmpn$ gpg --try-secret-key test --decrypt test.asc
gpg: anonymous recipient; trying secret key 82A22A9306735B0C ...
gpg: okay, we are the anonymous recipient.
gpg: encrypted with RSA key, ID 00000000
test test
0 dkg@alice:/tmp/cdtemp.hphmpn$

Sorry, this is a duplicate of T2391. apparently i accidentally
double-clicked and roundup doesn't protect against that sort of thing. :/

(that last comment was with 2.1.13)

fwiw, when i'm on a network that doesn't support IPv6, i get this:

0 dkg@alice:~$ gpg --send $KEYID
gpg: sending key REDACTED to hkps://hkps.pool.sks-keyservers.net
gpg: keyserver send failed: Invalid argument
gpg: keyserver send failed: Invalid argument
2 dkg@alice:~$

in dirmngr's logs:

2016-06-17 19:30:17 dirmngr[27999.2] DBG: gnutls:L3: ASSERT: mpi.c:246
2016-06-17 19:30:17 dirmngr[27999.2] DBG: gnutls:L5: REC[0x7f61f400fc10]:
Allocating epoch #0
2016-06-17 19:30:17 dirmngr[27999.2] can't connect to '2001:ba8:1f1:f2d4::2':
Invalid argument
2016-06-17 19:30:17 dirmngr[27999.2] error connecting to
'https://[2001:ba8:1f1:f2d4::2]:443': Invalid argument
2016-06-17 19:30:17 dirmngr[27999.2] DBG: gnutls:L5: REC[0x7f61f400fc10]: Start
of epoch cleanup
2016-06-17 19:30:17 dirmngr[27999.2] DBG: gnutls:L5: REC[0x7f61f400fc10]: End of
epoch cleanup

I think this instance of dirmngr was started on a network that has both IPv4 and
IPv6.

if i do:

     gpg-connect-agent --dirmngr killdirmngr /bye

and then try the --send again, it goes through fine.

We could bail early if we see something like this.

But since percent-unescaping is supposed to be able to handle arbitrary
characters (and consumers of this data have to percent-unescape anyway), why not
escape the record separator instead of bailing?

This looks great to me. I've always been frustrated by the c+p difficulty.

Does it make sense to put an "fpr" at the beginning of the fingerprint line, to
match with "pub" and "uid" ?

For example:

pub dsa2048 2007-12-31 [SC] [expires: 2018-12-31]
fpr 80615870F5BAD690333686D0F2AD85AC1E42B367
uid [ full ] Werner Koch <wk@gnupg.org>

Have you started work on this change or would you like patches?

(btw, "fingerprint" should be 40 hex chars, not 32 as if suggested)

For modern gnupg, we no longer support v3 keys, and we're considering making
--with-fingerprint the default (see
https://lists.gnupg.org/pipermail/gnupg-devel/2016-January/030748.html), so i
think this suggestion should actually be reconsidered.

fwiw, i first encountered this by doing a full-keyring refresh from the
keyservers. Dying rather than adjusting or accomodating the malformed header
meant that all keys after this one failed to refresh.

In general, dying outright seems likely to make an observed problem worse than
it needs to be.

I'm not convinced that this policy is effectively implemented in gpg-agent.

The patch series that starts here:

https://lists.gnupg.org/pipermail/gnupg-devel/2016-May/031121.html

resolves the export of secret key material stored as cleartext, and it does so
without modifying gpg-agent at all.

fwiw, I do not agree with T2324 (justus on Apr 18 2016, 05:22 PM / Roundup) that gpg --batch should not use pinentry at
all -- i think it's quite useful to be able to combine --batch with pinentry,
where the key is stored protected, or is otherwise marked by gpg-agent for
limited use.

I don't think this is actually resolved.

As noted in https://lists.gnupg.org/pipermail/gnupg-devel/2016-April/031032.html
, gpgv accepts signatures made from revoked or expired keys.

It should reject signatures made from keys it believes to be revoked or expired.

The attached tarball contains:

     pubkey.gpg -- a binary-format 2048-bit RSA OpenPGP certificate

     C47D9EDFF117EE2AA11B162D017D715B3D0C4AF2.key -- the corresponding
                                                     secret key (for
                                                     reference/experimentation
                                                     only)

     before.txt.asc -- clearsigned message made by the key before
                       certificate creation time

     during.txt.asc -- clearsigned message made by the key between
                       certificate creation and certificate expiration

     after.txt.asc -- clearsigned message made by the key after certificate
                      expiration

of these, gpg approves of during.txt.asc and after.txt.asc, but not before.txt.asc.

Thanks for the explanation, Werner.

This note might also be worth adding to the gpg-preset-passphrase manpage.

Thanks for looking into this, Justus.

While you're working on this, it might make sense to consider restoration of the
--export-options export-reset-subkey-passwd flag, which was dropped in 2.1.

This flag was used by at least one GnuPG downstream (monkeysphere); its absence
causes "monkeysphere subkey-to-ssh-agent" to fail.

In GnuPG 1.4.x and 2.0.x, the option was defined this way:

export-reset-subkey-passwd
       When  using  the  --export-secret-subkeys  command,  this
       option resets the passphrases for all exported subkeys to
       empty. This is useful when the exported subkey is  to  be
       used  on an unattended machine where a passphrase doesn't
       necessarily make sense. Defaults to no.

furthermore, if the user enters an empty password, gpg-agent says "please
confirm that you do not want to have any protection on your key".

If the user chooses "yes, protection is not needed" in this followup prompt, gpg
*still* refuses to export the secret key, producing this error message:

---------------

gpg: key 0CA2C754F8DF3194EC1F1C7EF88AEA8D20BAFB0F: error receiving key from
agent: No passphrase given - skipped

gpg: WARNING: nothing exported

I understand the reason for re-encrypting -- i'm quite happy that the agent is
sensible about improving the security of the key when it adopts it.

my concern is that users don't know what to expect, and that different workflows
result in different sets of keys stored in the agent.

So i'd recommend that when importing without --batch, if the password fails for
any reason, gpg should fall back to the fast migration "kludge" rather than just
skipping that keyblock. That way the imported secret key material will still be
available and can be cleaned up/hardened on first successful use.

I'm not convinced that the +-prefixed lines address clint's concern.

In particular, the parenthetical remark "(domain means the domain part of the
mail address)" is the important bit -- will this be documented somewhere?

I'm changing this from "nobug" to "bug", because it is clearly causing problems
for people with separate per-device signing keys, or with multiple smartcards
(e.g. work and home)

I don't think this is a doc or FAQ issue, i think it's an actual bug that has a
significant effect on usability.

If gpg has an available key that would work, it should use it, rather than
preferring the unavailable key.

If the user explicitly specifies an unavailable subkey then sure, gpg should
fail. But if they've only specified their primary (or their UID) then gpg
should be willing to use any available active (non-revoked, non-expired) subkey
with the right usage flags instead of failing if an unavailable one has a newer
date.

fwiw, i've now got most of GnuPG cross-building for win32 from a debian platform
using win-iconv. win-iconv doesn't seem to be a terrible choice to me.

I'm also interested in this, since i want to make it possible to easily build a
win32 version of gpgv.exe on debian systems. This is possible without iconv at
all in 1.4.x, but i would rather we ship a gpgv from 2.1.x in the future.

I'm happy to see GnuPG moving to an all-agent model, where the passphrase and
the asymmetric secret key material aren't available to the gpg process.

That sai, if gpgme is going to remove the passphrase_cb prompt, or to deprecate
it in all cases other than symmetric data encryption/decryption, then should the
API change?

gpgme_set_passphrase_cb is used in about 40 packages in debian:

  https://codesearch.debian.net/results/gpgme_set_passphrase_cb/page_0

this includes bindings for python, ruby, php, and c++ -- and it's possible that
those bindings themselves have some other usage elsewhere.

Do we have guidance for users of this function, whether it's with gpgme
directly, or with any of the bindings?

Hm, this is indeed fixed for pinentry-gtk2 and pinentry-gnome3, but pinentry-qt
is still broken:

0 $ DISPLAY=:3 pinentry-qt
QXcbConnection: Could not connect to display :3
Aborted
134 $

I'm attaching an updated patch that doesn't just ship sks-keyservers.netCA.pem
in the distributed tarball, but installs it during "make install" in pkgdatadir,
and then checks during query time to see if it should be used.

In particular, if the user asks for "hkps://hkps.pool.sks-keyservers.net" and
they haven't specified any hkp-cacert argument in dirmngr, it automatically
tries to load the bundled cert.