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
| rG GnuPG | |||
| rG72fe8d652fce scd: Bring back --card-timeout option as deprecated. | |||
| rG4262933ef6f7 scd: Remove unsupported --card-timeout option. | |||
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | None | T3362 Prevent Smartcard from caching PIN when cache-ttl is set accordingly | ||
| Open | • gniibe | T3383 scdaemon option 'card-timeout' does not have any effect |
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.
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.
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.
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.