I close this one. An implementation is already in master.

Duplicate of T2819

Done with commit 35023f3.

I modified the patch slighly, added docs and a --from-file to run-keylist.
You may want to add a C== and Qt interface.

Merged in 6c45eed62214b44fcc11e642b19df7b6ca0da0bd.

Let's keep this one open to track missing options.

Finally fixed in 2.0.11
(restored T1001 (wk on Mar 03 2009, 04:58 PM / Roundup))

Simple workaround is having multiple readers...

Most card readers only support a single card.
(This is the reason why it is not yet implemented.)
Could you please let us know the reader which supports multiple cards?

I was actually surprised to find out this doesn't already work...

I would like to be able to have two or more GnuPG cards inserted at the same
time, and have gnupg/gpg-agent/scdaemon notice all of them and use whichever one
was appropriate for the operation at hand, without my having to switch them in
and out.

My personal application for this is that I have a personal key and a work key,
and I want to be able to sign with either of them without having to swap
hardware around. It's pretty easy to set up all the other parts of this to be
seamless with Thunderbird/Enigmail/gnupg2... it works fine until you move the
keys to cards, at which point gnupg's inability to automatically choose the card
it needs really shows up.

In an ideal world, this would also work with gpg-agent as a backend for ssh.

As of d379a0174cca595204b32da9a66c513a1304e6d0 auto-key-retrieve is configurable.

As of ebeccd73eb85f9027f0985d77dfe901266c6ddef the trust model is configurable
via gpgconf.

D409: 954_0001_gnupg-2.1.18_allow-original-timestamp-on-keysig-update.patch

Testing this I noticed that the curses fallback did not work at all for Qt5
versions of pinentry-qt even if display was unset. This i fixed with cd7b35e

But the DISPLAY=:noexist case is more complicated. The GTK pinentry does a
gtk_init_check which Qt does not have. I don't want to mess with X directly and
would have to look into this more how to do this then only when X is used etc.

There is a similar question on stackoverflow and I don't find any answers there
acceptable:
http://stackoverflow.com/questions/28525435/qt-equivalent-to-gtk-init-check

I've changed the topic to reflect that this is a feature currently not available
in pinentry-qt but I don't see it as a high priority issue.

Andre, can you look at it?

Using a socket conenction would require new code. We use the standard ports
instead. Sometimes the socks5 code (and I assume also the Unix domain socket
code) takes some time to figure out whether Tor is actually running, Thus this
is not done at every request.

Doing a check for every request would also require a lot of new code because we
need to restart a connection attempt at a higher layer. Similar to HTTP 301
handling.

The whole point of a daemon is that is idling in the background to wait for work.

A more useful feature would be to flush the passphrase cache when the user is
not anymore logged in. But for Debian this has already been done by --supervised.

I agree about that race condition being an important thing to consider, but i
think it's orthogonal to whether the process is self-terminating.

That is: we need to consider that race condition even in the case of deliberate
shutdown too, right?

Do we have a test case that involves two concurrent processes, one that tries to
stop the agent, and the other that tries to access it?

One thing to look out for is a race condition between the agent deciding to shut
down, and a client trying to connect at that time, and that might lead to
intermittent failures. It may be doable correctly, but it is something to look
out for.

The other point being raised in the bug report about older daemons hanging
around over package upgrades should be discussed in a different bug. Yes,
shutting down the daemon when idle may work around this issue sometimes, but
clearly this is not a robust solution.

anyone skilled in qt want to fix this outstanding issue?

I've tested Simon's patch against 2.1.18, and i think it's the right thing. I
posted it to the mailing list in git-format-patch form here:

https://lists.gnupg.org/pipermail/gnupg-devel/2017-February/032547.html

Any progress on this?

A reproducer, even without smartcards (please ensure that GNUPGHOME is
explicitly set):

ARGS="--pinentry-mode loopback --passphrase abc123"
ARGS="$ARGS --batch --with-colons --with-keygrip --status-fd 3"

gpg $ARGS --quick-gen test@example.org rsa cert 3>genkey.status
FPR=$(awk '/KEY_CREATED/{ print $4 }' < genkey.status)
gpg $ARGS --quick-add-key 0x$FPR rsa sign 3>addkey-1.status
sleep 5
gpg $ARGS --quick-add-key 0x$FPR rsa sign 3>addkey-2.status
GRIP=$(gpg $ARGS --list-keys | grep ^grp: | cut -f10 -d: | tail -n1)
mv $GNUPGHOME/private-keys-v1.d/$GRIP.,bak
gpg-connect-agent killagent /bye
echo test | gpg $ARGS -u "$FPR" --clear-sign

This was included in 2.0.30, but somehow was missing from the 2.1.x branch.
I've included it in master as of 8a9d4b55b09d04482b46055f0a60f01b86738df3

Thanks for this work (and sorry to have just blindly/wrongly assumed that
--no-use-tor already existed without checking it).

On modern debian systems, the default tor daemon will always be listening on
unix domain socket /run/tor/socks. So a simple attempt to connect to that
socket should be sufficient -- it should fail immediately if the socket isn't
present or if no one is listening on it.

This seems cheap and fast enough to be able to do it on every query to me,
rather than introducing additional runtime state to dirmngr. just try to
connect, and if it doesn't work, fall back to a normal connection (you'd want to
do that anyway in case the tor daemon goes away after dirmngr had been launched).

justus: we recently talked about this. Would you like to work on this. I am in
particular interested to use it for Windows statically linked.

Okay, that first part has been pushed. Now need to figure out how to test for
Tor in a clean way.

I will do some rework to make testing for tor easier ....

I think this is a good idea. If Tor is already running we can expect that the
user wants to use Tor as much as possible and thus tehre should be no need for
any configuration.

I do not think that we need a new option (except for making --no-use-tor). To
avoid checking for tor with every new connection to Dirmngr, I would do a test
at startup and after each reload.

Please take such discussions to the mailing lists. As soon as a resolution has
been found please update the status of this bug.

This is because your idea of security is wrong in two different aspects.

First: you assume that you just need to call or declare a system as
„trustworthy”, and then it would stop to ever have any bug, failure, or any sort
of malfunction. "Secure" and "Trustworthy" are not absolute properties of a
device, they are always relative to a given threat or attack vector, and these
security terms do not cover normal bugs oder mistakes made by operators. Having
a „trustworthy” system does not mean that it would not write a secret key on a
storage device if you accidently ask it to do so (e.g. because you still have a
CWD in the device when running any key related software. So you need to avoid
that bad operation or malware could leak the secret keys out of the device, and
it won't help in any way to call the device „trustworthy”.

Second: You erroneously apply the term „trustworthy” to a storage device. Trust
belongs to the area of system security, while mobile storage devices (as stupid
read-write-devices) belong to communication security. In communication security
there is no trust. A regular (perfect) storage device is something where you can
write data, and read it later, no matter whether you trust it or not. You cannot
write a message on a storage device and hope that an attacker would not read it,
unless it is part of a system (which it is not if it is, as you intend, a mobile
device which is to be connected to another, insecure machine.)

Things get worse, since thumb drives are not perfect storage devices, but little
systems just pretending to be one. Putting a trusted and an untrusted system
together (i.e. putting a thumb drive into a computer) breaks the system security
of the first system.

Third: the current design is illogical and inconsistent. you use and create a
device (crypto usb device like yubikey) which is intended to protect the key
while making the key usable to the authorized user for doing cryptographical
operations, e.g. create signatures.

Good. That's what the device and it's API are designed for, and since there's
currently no better option available that's currently the best way to do it.

But then, if there is a well defined way, considered as secure, to use the key
for signatures (which might include some internal logging to track signatures),
why should there be a second, different way to create signatures, outside the
device, just to sign it's own public key record and ID (self certify)?

Why isn't it used the normal way for this special signature as well?

e.g. x509/SMIME/openssl do it correctly. They first create a pub/sec key pair
and then use a regular signature operation to generate a CSR oder self-cert.

If there is a well defined and secured way to create signatures, it's bad design
to use another operation just to selfcert without good reason.

And inventing the need to communicate with the outer world in an unprecise
protocol (which it is if you exchange large storage devices) which could
transmit just anything, stops the device from beeing trustworthy anymore.

It is wrong to think that you can exchange storage devices, because the system
was trustworthy. It's the other way round: It's not trustworthy anymore once you
allowed to communicate after key creation.

To me, your assumptions seem flawed. You somehow assume that you can get a
trustworthy computer A, but cannot get your hands on a trustworthy device to
transport data from A to B?

(Even if your assumptions hold, you can always take A apart and use its data
storage device (which is trustworthy) and use it to carry the public key.)

Fix is in 2.1.18

How you convey data between an air-gapped box and a the general desktop is out
of scope for GnuPG. This is OPSEC and you have to setup your rules. Aside from
USB sticks, it is possible to burn stuff to a CDROM, use a floppy, SD card, a
printer and a scanner, a camera and OCR, you name it in your security policy.

Please direct your question to a mailing list. I can't see why this is a
feature requests.

You can connect your token to the computer, but for some reason

cannot connect a thumb drive to it?

Exactly.

That's the point.

A token is a security device from a (hopefully) known manufacturer with a
(hopefully) well known API, where you can survey what data it carries out. You
need to use it (if you don't want to reveal your key as a file to unsecure
machines), and it is no surprise that it will carry the secret key. That's the
idea.

A thumb drive, on the other hand, is evil. You have a file system and lots of
hidden space on it, and you can't check what malware will hide on it or what
will be left on it simply by making mistakes or bad use of software (e.g. having
the CWD on the thumb drive while doing some crypto operations).

Furthermore, thumb drives are reprogrammable, sometimes quite easy. You can
teach regular thumb drives to behave like CDROMs, keyboards, just as any USB
device, and thumb drives are well known as an attack vector to bring in malware.

However, the major problem is not to connect the thumb drive to the secure
computer. It's not in general a bad idea to use a thumb drive as a backup
storage system for the secure computer.

It's a bad idea to connect it to any other machine after it. Once the thumb
drive has been connected to the secure machine, it should be considered as
contaminated with secrets and never be used outside the secure environment. So
your question somewhat missed the point.

However, the secure enviroment (secure computer and maybe thumb drives) should
be completely isolated (some people call it "air gapped") and the only
connection to the outer world should be what's absolutely needed and well
defined. And that's the token (which, after all, is exactly designed for that
purpose).

If A is to be kept *really* secure, it must not have any network contact

Agreed.

and not
export any files from the point of time where the keys is generated.

I don't follow. You can connect your token to the computer, but for some reason
cannot connect a thumb drive to it? I don't see why exporting data from that
computer is problematic. If you are worried about compromised USB devices, you
should also be worried about the computer being manipulated in the first place,
or the openpgp token. Furthermore, you could use the computers screen to export
any information.

FTR: EFL == enlightenment foundation libraries. Calling this
"Enlightenment-based" is like calling the GTK pinentry "Metacity-based".

It does work, but contrary to my expectations it is rather unpolished. I'll
talk to Mike.

Done now

I currently know of no more problems so lets resolve this.

In 2.1 --quit is honored here

There are keyservers which listen on port 80 or 443. They can be used in such
cases. See https://sks-keyserver.net.