PIN caching with gnupg-1.4.2-rc2 and gpg-agent 1.9.17

[Werner Koch]

On Fri, 15 Jul 2005 13:33:51 +0300, Joachim Breitner said:

> When I sign a file with gnupg, daemon running, no scdaemon, it seems as
> if gnupg asks the agent to ask me for the pin, but talks itself to the
> card. When I repeat that, the agent obviously has already cached the PIN
> and I don't have to enter it again. So far so good.

Yes, in this case gpg-agent is only used to cache the PIN/passphrase.

> When I do enable scdaemon (using pcscd), signing works as well, but the
> PIN does not seem to be cached: I have to enter it again.

I also noticed that and looking for a solution.  Actually the card
should cache the PIN and thus no gpg-agent caching is involved at all.
However any RESET to the card will let the card forget the PIN.  Now,
when a connection to the gpg-agent/scdaemon terminates a reset is send
down to the card handlers.  It seems that this is a full reset down to
the card instead of a mere connection cleanup.

> Also, with scdaemon, there might be problems with other programs using
> the smartcard, e.g. HBCI, but also libpam-poldi. Haven't investigated
> that though.

I already talked with Moritz about this.  In general it should not
happen because gpg-agent is started after a successful login and poldi
needs then to relinquish control over the card reader.  The problem
seems to be any PAM access later on (e.g. su).  We might need to watch
out for a running scdaemon and utilize it the same way as gpg does it.

> A different issue: If the card is not inserted, gpg will ask to insert
> the card on the prompt, expecting a keypress. This breaks usage with
> e.g. evolution. IMHO, gnupg should just wait for the card to be
> inserted, or for some timeout to run out, but not require user
> interaction on the console. If user interaction, then via the
> gpg-daemon, just like PIN entries.

Hmmm, this should not happen when calling gpg with --batch:

  if (rc && !opt.batch)
    {
      write_status_text (STATUS_CARDCTRL, "1");
      
      did_shutdown = !!apdu_shutdown_reader (slot);

      if ( cpr_get_answer_okay_cancel ("cardctrl.insert_card.okay",
           _("Please insert the card and hit return or enter 'c' to cancel: "),
                                       1) )

Even without that the answer expected to such a prompt should be
Return (i.e. sending an empty line to --command-fd).  Well of course,
the default answer is not very satisfying as this will lead to an
unifinite loop.  The correct solution for Evo would be to use --batch
or interpret the status messages and supply appropriate answers.

As a workaround I will add a retry limit to gpg 1.4.2.  The new option
"--limit-card-insert-tries N" must then be set to a positive value to
enable this.  A value of 1 won't issue the prompt, 0 (the default) will
emit the current behaviour.


Shalom-Salam,

   Werner