Given that gpg-agent is a per-user daemon, I believe this is a proper
assumption. As of now scdaemon gains exclusive access to the card and
thus no other scdaemon will be able to share the context. There is
one session per user and not a session per pty or whatever.

From: Simon Richter <Simon.Richter@hogyros.de>
To: bug-any@bugs.gnupg.org
Cc:
Subject: Re: gnupg/671
Date: Wed, 21 Jun 2006 20:26:58 +0200

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigDD4FF652D59E2B6969E8DBE3
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

> Given that gpg-agent is a per-user daemon, I believe this is a proper
> assumption. As of now scdaemon gains exclusive access to the card and
> thus no other scdaemon will be able to share the context. There is
> one session per user and not a session per pty or whatever.

Indeed, however multiple agent connections share the same context. As
the agent connection remains open while the gnupg process accessing the
agent is running, a single running gnupg process that takes long to
complete (I work with encrypted tar streams written to DVDs, for
example) will keep the context open; even if the agent forgets the PIN
after a few minutes of inactivity, newly started gnupg processes will
still be able to use the card without presenting a PIN.

Simon

--------------enigDD4FF652D59E2B6969E8DBE3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iQCVAwUBRJmPclYr4CN7gCINAQLYbwP7BAageRzDylG6OijaMTBmw3ZeLQFJc1I0
bJKmF2+6RXJ2ZAmK6KhHk3XwVgQIQUrOs1ORY4/vh218GfI+ePFgsUF6GBKxA134
GWfv+vWLg+KJ+NMYVTWOO3bGMiXtG+B+dSgiCa8Ip2O5PaEQEXqouX0jUyRGW6yU
Km5KzcfqzSI=
=5Zpb
-----END PGP SIGNATURE-----

--------------enigDD4FF652D59E2B6969E8DBE3--

I can see the problem. A solution for that will be to have gpg drop
the connection to the gpg-agent right when starting to decrypt the bulk data.
We need to see how this can be done in a clean way.

From: Simon Richter <Simon.Richter@hogyros.de>
To: bug-any@bugs.gnupg.org
Cc:
Subject: Re: gnupg/671
Date: Wed, 28 Jun 2006 14:58:45 +0200

Hi,

wk@gnupg.org schrieb:

> Synopsis: card context shared between callers

> I can see the problem. A solution for that will be to have gpg drop
> the connection to the gpg-agent right when starting to decrypt the bulk data.
> We need to see how this can be done in a clean way.

Wouldn't that still be a race condition (Albeit one that some users
explicitly ask for :-) )?

Simon

Needs to be fixed. Same problem also with gpgsm.