--use-agent is a dummy option in GnUPG 2.1 - it has no effect.

1.4 has been released - waiting for 2.0

I used your workaround and haven't been running into problems since. Unfortunately, I
don't currently have the time at hand to give it a thorough test run. If I do, I will
keep you updated.

gpg2 --use-agent --decrypt encrypted.asc
...
gpg: decryption failed: No secret key
FAIL

--use-agent --decrypt encrypted.asc
..
You need a passphrase to unlock the secret key for
...SUCCESS

This for example makes enigmail fail, and to make things worse: enigmail refuses
to work with gpg1

Using:
gpg (GnuPG) 2.1.11
libgcrypt 1.6.5
on Ubuntu 16.04.1 LTS

I have multiple keys in .gnupg, this might be triggering the problem.

Indeed; this look like a corrupted file. Please restrore from abckup.

ping

Could you verify that the problem has been solved (in 2.1.14)?

Done with commit d25db3c for 2.1.15

Already fixed in the repo. It is only a warning and harmless in this case.
Thanks.

This seems to be a general question on how to use the software. Please read the
HOWTOS at gnupg.org and if you still have questions ask at the gnupg-users
mailing list.

Yeah, at the moment I shoot scdaemon with SIGTERM whenever I need to use the PIV
app, which is rare, and have carefully avoided any kind of automated invocation
of the smartcard through scdaemon (e.g. my statusbar polls via ykinfo directly,
rather than invoking gpg --card-status.)

I know essentially nothing about smart cards or PC/SC's design, but what goes
wrong holding the card open shared rather than exclusively? Can other shared
lock holders do drastic things like insert or remove keys, causing scdaemon's
cache to become stale? I would have (naively) guessed that shared holders could
only do things like cryptographic operations which won't pose an issue to
scdaemon's cache. (Admittedly, cryptography is not side-effect free; counters
get incremented, random numbers get generated, but none of that is the kind of
thing that scdaemon caches, right?)

Thanks for thinking about this. :)

FYI.

https://lists.gnupg.org/pipermail/gnupg-devel/2016-August/031479.html
^-- In this experiment, I tried another half of supporting OpenSSH certificates.

I found that it doesn't work as I had thought.

I think that the lower level support of gpg-agent is ready to add this feature
of accepting OpenSSH certificates, but modification of OpenSSH will be required
too, so that it works well.

Currently, the OpenSSH certificate file itself is still needed even if ssh-agent
supports OpenSSH certificates. When it returns a certificate to ssh client, ssh
client only uses the information of the key in the certificate. It is the file
which ssh client uses communicating to the server.

Scdaemon grabs the device after its first use; it gets information on the
card/token and it operates (sign/decrypt) based on those information. If it
releases the device, it should get the info.
Current design of scdaemon is state-full: it caches the information on the card
so that operations can be soon done.
more state-less design could be possible, with the cost of each operation will
be heavy (by getting information each time).

I don't know the PIV app of Yubikey, but, in most cases, such an app can be
written stopping scdaemon beforehand (by a line of gpgconf --reload scdaemon, if
it's a script). It's a simple workaround for now.

Fixed in 72fa314b.

Actually, I'd argue that tdbio_set_dbname did not handle this case correctly. In
any case, if you must create some temporary gnupghomes, deleting the whole
directory might be both easier and more robust.

Fixed in a27410a2.

I explained this already on the mailing list: gpg takes data from stdin but
sometimes need to ask on the tty for a passphrase or confirmation. If you do
not want this use --batch and --with-colons.

The --edit-key interface cannot be operated via stdin because this is a human
only interface. To automate --edit-key you need to use --status-fd and
--command-fd and apply an FSM for processing. This is required to keep the API
stable and to allow extending the --edit-key interface.

GnuPG 2.1 also has a bunch of new commands (--quick-foo) which can be used to do
the most common operations directly from the command line.

Well, the man page states

  --yes  Assume "yes" on most questions.

Note the "most" ;-)

I agree that there is no clear pattern. I tried to make use of --yes in way to
minimizes surprising loss of data. Can certainly be improved.

Can you please tell us what version of ssh you are using (ssh -V)?

To piggyback something on this issue.

To quote T2359 (aheinecke on May 17 2016, 11:59 AM / Roundup):

e.g. an API to check which key: gpg -er aheinecke@intevation.de

I did not have groups on the radar for this. If a recipient is a group then
gnupg would use multiple keys in this command.

I think locate-keys would be a great mechanism to support this easily in MUAs.
When we change it that for a given mailbox only the single most valid Key is
returned we could also have the semantic that if then multiple Keys are returned
we have a group.

Please describe the bug and your patch here. A long title is not a sufficient
description. tia.

https://pagure.io/pygpgme/c/6648b075fb3d434c599d7e1793bd1f0bbe85dfe3?branch=master says:

T767 indicates that

gpgme_set_passphrase_cb is a deprecated corner of the API and that
developers using gpgme should really rely on the gpg-agent to handle
this stuff.

That is not correct. gpgme_set_passphrase_cb is not deprecated, and gpg21 does honor the flag.
In fact, allow-loopback-pinentry is the default since GnuPG 2.1.12.

Will be a week or so. Had to power off my server due to "flooding" nearby.

Indeed, thanks for the analysis!

Fixed in 40365b28.

Fixed in c971ff08.

D198: 866_gnupg-2.1.14.diff

With T1590 irrelevant, issues 1862, 1970, and 2336 resolved (very special
thanks to everyone who helped in fixing them!), this is the only problem left in
version 2.1.14 that forces me to use a patched version of gpgsm for my webmailer.

My patch from 2014-04-30 works, but by mistake ("if (cmp < 0)" in place of "if
(cmp > 0)" it selects not the newest but the oldest one of the ambiguous
certificates what is bad in the DFN PKI because an older one of the certificates
is revoked, so I attach a new patch against 2.1.14.

Ok, I can record such files. Will there be any confidential information contained in
these logs?

AIX required a patch for Npth library for fork.
Please test again with npth 1.3 when it will be released.
I tested with 2.1.14, all go well successfully (make check no errors) with
patched version of Npth library.

I confirmed that with patched npth, 2.1.14 with
c49c43d7e4229fd9f1bc55e17fa32fdc334dbef6 builds well and "make check" goes
successfully (on AIX 7.1 with gcc 4.8.1).

Please test again when npth 1.3 will be released.

You can have a configuration file like:

.gnupg/gpg-agent.conf

enable-ssh-support
debug-level guru
debug-all

log-file /run/user/1000/gpg-agent.log

and

.gnupg/scdaemon.conf

debug-level guru
debug-all
debug-ccid-driver

log-file /run/user/1000/scd.log

so that the interactions can be recorded with debug information.

An option like --stdout-as-tty may also be needed,
for completeness, to avoid /dev/tty writes.

import-clean does call the same code, but it behaves differently for the key you
mention. I created a test key that does get cleaned up upon import.

Merged in 583a464c, thanks!

Note that we prefer contributions sent to the mailinglist using git send-email.