scdaemon option 'card-timeout' does not have any effect
Open, NormalPublic

Description

As recently mentioned here https://lists.gt.net/gnupg/users/81309 by me and by a Debian user here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701062 the scdaemon option "card-timeout" seems to do nothing. At least for openpgp smartcards.

Please check if this behavior can be fixed. Maybe the finding of the debian user helps (second link).

This option could be important for this feature request as well: https://dev.gnupg.org/T3362

Thanks alot

gniibe claimed this task.Sep 5 2017, 3:49 AM
gniibe triaged this task as Normal priority.
gniibe added a subscriber: gniibe.

Let me explain the situation.

In scdaemon manual, it explained as scdaemon will be powering down the smartcard by the value specified.
But, it never has been implemented as described.

In 2.0, it was a variable to control scdaemon to allow DISCONNECT command.
In 2.1, scdaemon has been improved to allow DISCONNECT command always.

Thus, it is true, this variable has no effect in 2.1.

jans added a subscriber: jans.Feb 5 2018, 6:08 PM
mrloop added a subscriber: mrloop.Feb 12 2018, 8:41 PM

I meant, 'card-timeout' was not intended for controlling caching PIN on card. It was for "DISCONNECT" command support.
I'm going to remove questionable documentation.
Closing.

gniibe closed this task as Resolved.Jun 4 2019, 3:01 AM
werner reopened this task as Open.Jun 4 2019, 7:45 AM
werner added a subscriber: werner.

I see a regression with your fix. This option is even controllable with gpgconf at the basic level. It would be better to make it a dummy option.

gniibe added a comment.Jun 4 2019, 8:46 AM

I see the regression of gpgconf. I wonder if it's better to fix gpgconf side, too.

It has been a dummy option for years (since GnuPG 2.1). For the record, I write more detail here.

It never worked as these bug reporter expected (directly control access from scdaemon to card by time out), it only changed the behavior of DISCONNECT command. A user required to issue DISCONNECT command anyway and the option could change how DISCONNECT was done. <-- This is 2.0.

Since 2.1, DISCONNECT command works well always, regardless of this option.